Я написав невеличку програму, яка взаємодіє із сервером на певному порту. Програма працює нормально, але:
Після того, як програма несподівано припинилася, і з тих пір це підключення до сокета відображається у CLOSE_WAITстані. Якщо я намагаюся запустити програму, вона зависає, і мені доводиться примусово її закривати, що накопичує ще більше CLOSE_WAIT сокетних з'єднань.
Чи є спосіб змити ці зв’язки?
Відповіді:
CLOSE_WAITозначає, що ваша програма все ще працює і не закрила сокет (і ядро чекає, поки це зробить). Додайте -pдо, netstatщоб отримати під, а потім вбийте його сильніше ( SIGKILLякщо потрібно). Це повинно позбутися ваших CLOSE_WAITрозеток. Ви також можете використовувати, psщоб знайти pid.
SO_REUSEADDRпризначений для серверів та TIME_WAITсокетів, тому тут не застосовується.
Як описав Кріст Кларк .
CLOSE_WAIT означає, що локальний кінець з'єднання отримав FIN з іншого кінця, але ОС чекає, поки програма на локальному кінці фактично закриє своє з'єднання.
Проблема в тому, що ваша програма, що працює на локальній машині, не закриває сокет. Це не проблема налаштування TCP. З’єднання може (і цілком правильно) залишатися в CLOSE_WAIT назавжди, поки програма тримає з'єднання відкритим.
Як тільки локальна програма закриє сокет, ОС може надіслати FIN на віддалений кінець, який переводить вас у LAST_ACK, поки ви чекаєте ACK FIN. Після отримання з'єднання закінчується і випадає з таблиці з'єднань (якщо ваш кінець знаходиться в CLOSE_WAIT, ви не потрапите в стан TIME_WAIT).
close()або closesocket(), залежно від того, яку платформу ви використовуєте.
У мене також виникає та сама проблема з найновішим сервером Tomcat (7.0.40). Він не реагує один раз на пару днів.
Щоб побачити відкриті з'єднання, ви можете використовувати:
sudo netstat -tonp | grep jsvc | grep --regexp="127.0.0.1:443" --regexp="127.0.0.1:80" | grep CLOSE_WAIT
Як згадувалось у цій публікації , ви можете використовувати /proc/sys/net/ipv4/tcp_keepalive_timeдля перегляду значень. Здається, значення в секундах і за замовчуванням становить 7200 (тобто 2 години).
Щоб їх змінити, потрібно відредагувати /etc/sysctl.conf.
Open/create `/etc/sysctl.conf`
Add `net.ipv4.tcp_keepalive_time = 120` and save the file
Invoke `sysctl -p /etc/sysctl.conf`
Verify using `cat /proc/sys/net/ipv4/tcp_keepalive_time`
Незважаючи на те, що занадто багато з'єднань CLOSE_WAIT означає, що з вашим кодом спочатку щось не так, і це прийнято недоброю практикою.
Можливо, ви захочете перевірити: https://github.com/rghose/kill-close-wait-connections
Цей сценарій робить так, щоб надіслати ACK, на який очікувало з'єднання.
Це те, що мені вдалося.
Слід зазначити, що Socketекземпляр як на клієнтському, так і на кінцевому сервері повинен явно викликати close(). Якщо close()тоді викличе лише один із кінців , сокет залишиться в стані CLOSE_WAIT.
Ви можете примусово закрити сокети ssкомандою; ssкоманда є інструментом , використовуваним для дампа статистики сокетов і відображає інформацію на кшталт (хоча простіше і швидше) NetStat.
Щоб убити будь-який сокет у стані CLOSE_WAIT, запустіть це (як root)
$ ss --tcp state CLOSE-WAIT --kill
Варто також зазначити, що якщо ваша програма породжує новий процес, цей процес може успадкувати всі ваші відкриті дескриптори. Навіть після закриття вашої програми ці успадковані дескриптори все ще можуть залишатися живими через процес осиротіння дитини. І вони не обов'язково відображаються абсолютно однаковими в netstat. Але все одно сокет буде зависати в CLOSE_WAIT, поки цей дочірній процес живий.
У мене був випадок, коли я керував АБР. ADB сам породжує процес сервера, якщо він ще не запущений. Спочатку це успадкувало всі мої дескриптори, але не виявилося власником жодного з них, коли я проводив розслідування (те саме стосувалося і macOS, і Windows - не впевнений у Linux).