Uma quantidade enorme de conexões TIME_WAIT indica netstat

Question

Ok, isso está me assustando - vejo cerca de 1500-2500 deles:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

Esse número está mudando rapidamente.

Eu tenho uma configuração bem apertada do iptables, então não tenho idéia do que pode causar isso. alguma idéia?

Obrigado,

Tamas

Editar: saída de 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               

    

Answer 1

Como mencionado por outros, ter algumas conexões em TIME_WAIT é uma parte normal da conexão TCP. Você pode ver o intervalo examinando /proc/sys/net/ipv4/tcp_fin_timeout :

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

Altere-o modificando esse valor:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Ou permanentemente, adicionando-o ao /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Além disso, se você não usar o serviço RPC ou o NFS, basta desativá-lo:

/etc/init.d/nfsd stop

e desligue-o completamente

chkconfig nfsd off

    

Answer 2

TIME_WAIT é normal. É um estado após o fechamento de um soquete, usado pelo kernel para rastrear pacotes que podem ter sido perdidos e atrasados para a festa. Um grande número de conexões TIME_WAIT é um sintoma de obter muitas conexões de curta duração, e não há nada com que se preocupar.

    

Answer 3

Algo em seu sistema está fazendo muitas RPC (Chamadas de Procedimento Remoto) em seu sistema (note que tanto a origem quanto o destino são localhost). Isso é frequentemente visto para lockd para montagens NFS, mas você também pode vê-lo para outras chamadas RPC como rpc.statd ou rpc.spray.

Você pode tentar usar "lsof -i" para ver quem tem esses sockets abertos e ver o que está fazendo isso. Provavelmente é inofensivo.

    

Answer 4

Não é importante. Tudo o que significa é que você está abrindo e fechando muitas conexões TCP Sun RCP (1500-2500 delas a cada 2-4 minutos). O estado TIME_WAIT é o que um soquete entra quando é fechado, para impedir que as mensagens cheguem para os aplicativos errados, como acontece se o soquete for reutilizado muito rapidamente e para outros fins úteis. Não se preocupe com isso.

(A menos, é claro, você não esteja realmente executando nada que deveria estar processando muitas operações de RCP. Então, se preocupe.)

    

Answer 5

Eu também tive o mesmo problema. Eu me custou várias horas para descobrir o que está acontecendo. No meu caso, a razão para isso foi que netstat tenta procurar o nome do host correspondente ao IP (suponho que esteja usando a API gethostbyaddr). Eu estava usando uma instalação Linux integrada que não tinha /etc/nsswitch.conf. Para minha surpresa, o problema só existe quando você está realmente fazendo um netstat -a (descobriu isso executando o portmap no modo detalhado e de depuração).

Agora, o que aconteceu foi o seguinte: Por padrão, as funções de pesquisa também tentam entrar em contato com o daemon ypbind (Sun Yellow Pages, também conhecido como NIS) para consultar um nome de host. Para consultar esse serviço, o portmapper portmapper deve ser contatado para obter a porta desse serviço. Agora o portmapper no meu caso foi contatado via TCP. O portmapper então diz à função libc que tal serviço não existe e a conexão TCP é fechada. Como sabemos, as conexões TCP fechadas entram em um estado TIME_WAIT por algum tempo. Assim, o netstat captura essa conexão ao listar e essa nova linha com um novo IP emite uma nova solicitação que gera uma nova conexão no estado TIME_WAIT e assim por diante ...

Para resolver este problema, crie um /etc/nsswitch.conf que não esteja usando os serviços RIS do NIS, ou seja, com o seguinte conteúdo:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files