Conexões órfãs no estado CLOSE_WAIT

Eu tenho uma máquina SLES que acumula conexões TCP em um estado CLOSE_WAIT pelo que parece ser para sempre. Esses descritores acabam sugando toda a memória disponível. No momento, tenho 3037 deles, mas foi muito maior antes de uma reinicialização apressada recentemente.

O interessante é que eles não são de conexões com portas locais que eu espero ter processos de escuta. Eles não têm PIDs associados e seus cronômetros parecem ter expirado.

# 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  -     

Eu não sou faixa-preta quando se trata da pilha TCP ou da rede do kernel, mas a configuração do TCP parece sã, já que esses valores são padrão, de acordo com a página de manual:

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

Então, o que dá? Se os temporizadores expiraram, a pilha não deve limpar automaticamente essas coisas? Estou efetivamente me dando uma declaração de longo prazo à medida que essas coisas se desenvolvem.

Não, não há tempo limite para CLOSE_WAIT. Eu acho que é isso que offsignifica a sua saída.

Para sair CLOSE_WAIT, o aplicativo precisa fechar o soquete explicitamente (ou sair).

Veja Como quebrar o CLOSE_WAIT .

Se netstatestiver sendo exibido -na coluna do processo:

• você está executando com os privilégios e capacidades apropriados (por exemplo, como root)?
• eles podem ser processos do kernel (por exemplo, nfsd)

CLOSE_WAITindica que o cliente está fechando a conexão, mas o aplicativo ainda não a fechou, ou o cliente não está. Você deve identificar qual programa ou programas estão tendo esse problema. Tente usar netstat -tonp 2>&1 | grep CLOSEpara determinar quais programas estão mantendo as conexões.

Se não houver programas listados, o serviço está sendo fornecido pelo kernel. Esses são prováveis ​​serviços RPC, como nfsou rpc.lockd. Os serviços de kernel de escuta podem ser listados com netstat -lntp 2>&1 | grep -- -.

A menos que os serviços RPC tenham sido vinculados a portas fixas, eles serão vinculados a portas efêmeras, conforme as conexões parecem mostrar. Você também pode verificar os processos e montagens no outro servidor.

Você pode ligar seus serviços NFS a portas fixas, fazendo o seguinte:

1. Selecione quatro portas não utilizadas para NFS (32763-32766 usadas aqui)
2. Adicione portas fixas para NFS ao /etc/services

   rpc.statd-bc 32763 / udp # transmissão statd RCP
   rpc.statd-bc 32763 / tcp
   rpc.statd 32764 / udp # RCP statd listen
   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. Configure statd para usar as opções --port 32763 --outgoing-port 32764
4. Configure rpcmountd para usar a opção --port 32765
5. Encerre e reinicie os serviços NFS e RPC.