Conexões órfãs no estado CLOSE_WAIT

Question

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

O interessante é que eles não são de conexões para portas locais que eu espero que tenham processos de escuta. Eles não têm PIDs associados e seus timers 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 sensata, já que esses valores são padrão, de acordo com a página man:

# 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 timers tiverem expirado, a pilha não deve limpar automaticamente essas coisas? Estou efetivamente me dando um DoS de longo prazo à medida que essas coisas se acumulam.

    

Answer 1

Não, não há tempo limite para CLOSE_WAIT . Acho que é isso que o off significa na sua saída.

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

Veja Como quebrar CLOSE_WAIT .

Se netstat estiver exibindo - na coluna do processo:

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

Answer 2

CLOSE_WAIT indica 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 programa está tendo esse problema. Tente usar netstat -tonp 2>&1 | grep CLOSE para determinar quais programas mantêm as conexões.

Se não houver programas listados, o serviço está sendo fornecido pelo kernel. Esses são provavelmente serviços RPC, como nfs ou rpc.lockd . Os serviços de escuta do kernel 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 suas conexões parecem ser exibidas. Você também pode querer verificar os processos e montagens no outro servidor.

Você pode conseguir vincular seus serviços NFS a portas fixas fazendo o seguinte:

1. Selecione quatro portas não usadas para o NFS (32763-32766 usado aqui)
2. Adicionar portas fixas para NFS a /etc/services

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