Connessioni orfane nello stato CLOSE_WAIT

Ho una macchina SLES che accumula connessioni TCP in uno stato CLOSE_WAIT per quello che sembra essere per sempre. Questi descrittori alla fine assorbono tutta la memoria disponibile. Al momento, ne ho 3037, ma era molto più alto prima di un riavvio rapido 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 stack TCP o della 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.

No, non è previsto alcun timeout per CLOSE_WAIT. Penso che sia questo il offsignificato nel tuo output.

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

Vedi Come interrompere CLOSE_WAIT .

Se netstatviene visualizzato -nella colonna del processo:

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

CLOSE_WAITindica 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 utilizzare netstat -tonp 2>&1 | grep CLOSEper determinare quali programmi trattengono le connessioni.

Se non ci sono programmi elencati, il servizio viene fornito dal kernel. Questi sono probabilmente servizi RPC come nfso 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.

Puoi essere in grado di associare i tuoi servizi NFS a porte fisse procedendo come segue:

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. Configurare rpcmountd per utilizzare l'opzione --port 32765
5. Arrestare e riavviare i servizi NFS e RPC.