Napisałem mały program, który współdziała z serwerem na określonym porcie. Program działa dobrze, ale:
Raz program zakończył się nieoczekiwanie i od tego czasu połączenie przez gniazdo jest pokazane w CLOSE_WAITstanie. Jeśli próbuję uruchomić program, zawiesza się i muszę wymusić jego zamknięcie, co gromadzi jeszcze więcej CLOSE_WAIT połączeń gniazd.
Czy istnieje sposób na przepłukanie tych połączeń?
Odpowiedzi:
CLOSE_WAIToznacza, że twój program nadal działa i nie zamknął gniazda (a jądro czeka, aż to zrobi). Dodaj -pdo, netstataby uzyskać pid, a następnie zabij go mocniej (w SIGKILLrazie potrzeby za pomocą). To powinno pozbyć się twoich CLOSE_WAITgniazd. Możesz również użyć, psaby znaleźć pid.
SO_REUSEADDRdotyczy serwerów i TIME_WAITgniazd, więc nie ma tutaj zastosowania.
Jak opisał Crist Clark .
CLOSE_WAIT oznacza, że lokalny koniec połączenia otrzymał FIN z drugiego końca, ale system operacyjny czeka, aż program na lokalnym końcu faktycznie zamknie połączenie.
Problem polega na tym, że program działający na komputerze lokalnym nie zamyka gniazda. Nie jest to kwestia strojenia TCP. Połączenie może (i całkiem poprawnie) pozostać w CLOSE_WAIT na zawsze, podczas gdy program utrzymuje je otwarte.
Gdy program lokalny zamknie gniazdo, system operacyjny może wysłać FIN do zdalnego końca, który przechodzi do LAST_ACK, podczas gdy czekasz na potwierdzenie FIN. Po odebraniu połączenie jest zakończone i znika z tabeli połączeń (jeśli twój koniec jest w CLOSE_WAIT, nie znajdziesz się w stanie TIME_WAIT).
close()lub closesocket(), w zależności od używanej platformy.
Mam również ten sam problem z najnowszym serwerem Tomcat (7.0.40). Nie reaguje raz na kilka dni.
Aby zobaczyć otwarte połączenia, możesz użyć:
sudo netstat -tonp | grep jsvc | grep --regexp="127.0.0.1:443" --regexp="127.0.0.1:80" | grep CLOSE_WAIT
Jak wspomniano w tym poście , możesz użyć, /proc/sys/net/ipv4/tcp_keepalive_timeaby wyświetlić wartości. Wydaje się, że wartość jest wyrażona w sekundach i domyślnie wynosi 7200 (tj. 2 godziny).
Aby je zmienić, musisz edytować /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`
Nawet jeśli zbyt wiele połączeń CLOSE_WAIT oznacza, że coś jest nie tak z twoim kodem w pierwszym i jest to akceptowane, nie jest dobrą praktyką.
Możesz sprawdzić: https://github.com/rghose/kill-close-wait-connections
To, co robi ten skrypt, to wysłanie ACK, na które czekało połączenie.
To właśnie zadziałało dla mnie.
Należy wspomnieć, że Socketinstancja po stronie klienta i serwera musi być jawnie wywoływana close(). Jeśli close()wywoła to również tylko jeden koniec , gniazdo pozostanie w stanie CLOSE_WAIT.
Możesz wymusić zamknięcie gniazd za pomocą sspolecenia; sskomenda jest narzędziem służącym do zrzutu statystyki gniazd i wyświetla informacje w podobny sposób (choć prostsze i szybsze) do netstat.
Aby zabić dowolne gniazdo w stanie CLOSE_WAIT, uruchom to (jako root)
$ ss --tcp state CLOSE-WAIT --kill
Warto również zauważyć, że jeśli program uruchomi nowy proces, ten proces może odziedziczyć wszystkie otwarte uchwyty. Nawet po zamknięciu własnego programu te odziedziczone uchwyty mogą nadal istnieć dzięki procesowi osieroconego dziecka. I niekoniecznie pojawiają się tak samo w netstacie. Ale mimo wszystko gniazdo będzie się kręcić w CLOSE_WAIT, gdy ten proces potomny będzie żył.
Miałem przypadek, w którym prowadziłem ADB. Sam ADB uruchamia proces serwera, jeśli nie jest jeszcze uruchomiony. To początkowo odziedziczyło wszystkie moje uchwyty, ale nie pojawiło się jako posiadanie żadnego z nich, gdy badałem (to samo dotyczyło zarówno systemu MacOS, jak i Windows - nie jestem pewien co do Linuksa).