it-swarm.it

Connessioni orfane nello stato CLOSE_WAIT

Ho una macchina SLES che accumula TCP connessioni in uno stato CLOSE_WAIT per quello che sembra essere per sempre. Questi descrittori alla fine assorbono tutta la memoria disponibile. Al momento, ho 3037 di loro, ma era molto più alto prima di un riavvio in fretta di recente.

La cosa interessante è che non provengono da connessioni a porte locali che mi aspetto di avere processi di ascolto. Non hanno PID associati e i loro timer sembrano essere scaduti.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

Non sono una cintura nera quando si tratta dello TCP o rete del kernel, ma la configurazione TCP sembra sana, poiché questi valori sono predefiniti , per la pagina man:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Quindi cosa dà? Se i timer sono scaduti, lo stack non dovrebbe eliminare automaticamente questa roba? Mi sto effettivamente dando un DoS a lungo termine man mano che queste cose si accumulano.

30
pboin

No, non esiste un timeout per CLOSE_WAIT. Penso che questo sia il significato di off nel tuo output.

Per uscire da CLOSE_WAIT, l'applicazione deve chiudere esplicitamente il socket (o uscire).

Vedi Come interrompere CLOSE_WAIT .

Se netstat mostra - nella colonna del processo:

  • stai correndo con i privilegi e le capacità appropriate (ad es. come root)?
  • potrebbero essere processi del kernel (ad esempio nfsd)
16
Mikel

CLOSE_WAIT indica che il client sta chiudendo la connessione ma l'applicazione non l'ha ancora chiusa, oppure il client non lo è. È necessario identificare quale programma o programmi hanno questo problema. Prova a usare

netstat -tonp 2>&1 | grep CLOSE

per determinare quali programmi trattengono le connessioni.

Se non ci sono programmi elencati, il servizio viene fornito dal kernel. Questi sono probabilmente servizi RPC come nfs o rpc.lockd. I servizi del kernel in ascolto possono essere elencati con

netstat -lntp 2>&1 | grep -- -  

A meno che i servizi RPC non siano stati associati a porte fisse, si legheranno a porte effimere come le connessioni sembrano mostrare. Potresti anche voler controllare i processi e i montaggi sull'altro server.

Potresti essere in grado di associare i tuoi servizi NFS a porte fisse nel modo seguente:

  1. Seleziona quattro porte non utilizzate per NFS (32763-32766 utilizzate qui)
  2. Aggiungi porte fisse per NFS a /etc/services
    rpc.statd-bc 32763/udp # RCP statd broadcast 
     rpc.statd-bc 32763/tcp 
     rpc.statd 32764/udp # RCP statd ascolta 
     rpc.statd 32764/tcp 
     rpc.mountd 32765/udp # RPC mountd 
     rpc.mountd 32765/tcp 
     rpc.lockd 32766/udp # RPC lockd/nlockmgr 
     rpc.lockd 32766/tcp
  3. Configura statd per utilizzare le opzioni --port 32763 --outgoing-port 32764
  4. Configura rpcmountd per utilizzare l'opzione --port 32765
  5. Arrestare e riavviare i servizi NFS e RPC.
10
BillThor