Почему соединения в состоянии FIN_WAIT2 не закрыты ядром Linux?
У меня есть проблема в долгоживущем процессе под названием kube-proxy, который является частью Kubernetes.
Проблема в том, что время от времени соединение остается в состоянии FIN_WAIT2.
$ sudo netstat -tpn | grep FIN_WAIT2
tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube-proxy
tcp6 0 0 10.244.0.1:48340 10.244.0.35:56339 FIN_WAIT2 14125/kube-proxy
tcp6 0 0 10.244.0.1:52619 10.244.0.35:57859 FIN_WAIT2 14125/kube-proxy
tcp6 0 0 10.244.0.1:33132 10.244.0.50:36466 FIN_WAIT2 14125/kube-proxy
Эти соединения со временем складываются, что приводит к неправильной работе процесса. Я уже сообщал о проблеме в баг-трекер Kubernetes, но я хотел бы понять, почему такие соединения не закрываются ядром Linux.
Согласно его документации (поиск tcp_fin_timeout) соединение в состоянии FIN_WAIT2 должно быть закрыто ядром через X секунд, где X можно прочитать из /proc. На моей машине установлено 60:
$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60
поэтому, если я правильно понимаю, такие соединения должны быть закрыты на 60 секунд. Но это не тот случай, они остаются в таком состоянии на несколько часов.
Хотя я также понимаю, что соединения FIN_WAIT2 довольно необычны (это означает, что хост ожидает некоторого подтверждения от удаленного конца соединения, которое уже может быть прервано), я не понимаю, почему эти соединения не "закрываются" системой,
Могу ли я что-нибудь с этим сделать?
Обратите внимание, что перезапуск связанного процесса является последним средством.
2 ответа
Время ожидания ядра применяется только в том случае, если соединение потеряно. Если соединение все еще подключено к сокету, программа, которой принадлежит этот сокет, отвечает за тайм-аут отключения соединения. Вероятно, это вызвало shutdown и ждет, пока соединение завершит работу чисто. Приложение может ждать, пока оно хочет, чтобы завершение работы завершилось.
Типичный поток чистого отключения выглядит следующим образом:
Приложение решает завершить соединение и закрывает сторону записи соединения.
Приложение ожидает, пока другая сторона отключит свою половину соединения.
Приложение обнаруживает отключение соединения на другой стороне и закрывает его сокет.
Приложение может ждать на шаге 2 столько времени, сколько пожелает.
Похоже, приложение требует тайм-аут. Как только он решит закрыть соединение, он должен перестать ждать, пока другая сторона выполнит чистое отключение через некоторое разумное время.
Если сокет является shutdown(), но еще не закрыт (), сокет останется в состоянии FIN_WAIT2. И поскольку приложение все еще владеет дескриптором файла, ядро не потрудится выполнить его очистку.