Ho scritto un piccolo programma che interagisce con un server su una porta specifica. Il programma funziona bene, ma:
Una volta che il programma è terminato in modo imprevisto, e da allora la connessione socket viene mostrata nello CLOSE_WAITstato. Se provo a eseguire un programma si blocca e devo forzare la chiusura, il che accumula ancora più CLOSE_WAIT connessioni socket.
C'è un modo per svuotare queste connessioni?
Risposte:
CLOSE_WAITsignifica che il tuo programma è ancora in esecuzione e non ha chiuso il socket (e il kernel sta aspettando che lo faccia). Aggiungi -pa netstatper ottenere il pid, quindi uccidilo con più forza (con SIGKILLse necessario). Questo dovrebbe sbarazzarti delle tue CLOSE_WAITprese. Puoi anche usare psper trovare il pid.
SO_REUSEADDRè per server e TIME_WAITsocket, quindi non si applica qui.
Come descritto da Crist Clark .
CLOSE_WAIT significa che l'estremità locale della connessione ha ricevuto un FIN dall'altra estremità, ma il sistema operativo sta aspettando che il programma all'estremità locale chiuda effettivamente la sua connessione.
Il problema è che il tuo programma in esecuzione sulla macchina locale non chiude il socket. Non è un problema di ottimizzazione TCP. Una connessione può (e abbastanza correttamente) rimanere in CLOSE_WAIT per sempre mentre il programma mantiene la connessione aperta.
Una volta che il programma locale chiude il socket, il sistema operativo può inviare il FIN all'estremità remota che ti fa passare a LAST_ACK mentre aspetti l'ACK del FIN. Una volta che si riceve, la connessione è finito e scende dalla tabella dei collegamenti (se il finale è in CLOSE_WAIT tu non finire in stato TIME_WAIT).
close()o closesocket(), a seconda della piattaforma che stai utilizzando.
Sto riscontrando lo stesso problema anche con un server Tomcat molto recente (7.0.40). Non risponde una volta per un paio di giorni.
Per vedere le connessioni aperte, puoi usare:
sudo netstat -tonp | grep jsvc | grep --regexp="127.0.0.1:443" --regexp="127.0.0.1:80" | grep CLOSE_WAIT
Come accennato in questo post , puoi utilizzare /proc/sys/net/ipv4/tcp_keepalive_timeper visualizzare i valori. Il valore sembra essere in secondi e il valore predefinito è 7200 (cioè 2 ore).
Per cambiarli, devi modificare /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`
Anche se un numero eccessivo di connessioni CLOSE_WAIT significa che c'è qualcosa di sbagliato nel tuo codice nel primo e questo è accettato non è una buona pratica.
Potresti voler controllare: https://github.com/rghose/kill-close-wait-connections
Quello che fa questo script è inviare l'ACK che la connessione stava aspettando.
Questo è ciò che ha funzionato per me.
Va ricordato che l' Socketistanza sia sul client che sul server deve essere invocata esplicitamente close(). Se solo una delle estremità invoca close()anche allora, il socket rimarrà nello stato CLOSE_WAIT.
Puoi chiudere forzatamente i socket con il sscomando; il sscomando è uno strumento utilizzato per scaricare le statistiche sui socket e visualizza le informazioni in modo simile (sebbene più semplice e veloce) a netstat.
Per uccidere qualsiasi socket nello stato CLOSE_WAIT, eseguilo (come root)
$ ss --tcp state CLOSE-WAIT --kill
Vale anche la pena notare che se il tuo programma genera un nuovo processo, quel processo potrebbe ereditare tutti gli handle aperti. Anche dopo il blocco del programma, gli handle ereditati possono essere ancora attivi tramite il processo del bambino orfano. E non si presentano necessariamente allo stesso modo in netstat. Tuttavia, il socket rimarrà in sospeso in CLOSE_WAIT mentre questo processo figlio è attivo.
Ho avuto un caso in cui gestivo ADB. Lo stesso ADB genera un processo del server se non è già in esecuzione. Questo ha ereditato inizialmente tutti i miei handle, ma non si è rivelato il proprietario di nessuno di essi quando stavo indagando (lo stesso valeva sia per macOS che per Windows - non sono sicuro di Linux).