Enorme quantidade de conexões TIME_WAIT, diz netstat

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

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 bastante apertada do iptables, então não tenho idéia do que pode causar isso. alguma ideia?

Obrigado,

Tamas

Edit: 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   -               

EDIT: tcp_fin_timeout NÃO controla a duração TIME_WAIT, é codificado permanentemente aos 60s

Como mencionado por outros, ter algumas conexões 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

E 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 NFS, poderá desativá-lo:

/etc/init.d/nfsd stop

E desligue-o completamente

chkconfig nfsd off

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

Isso 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 TIME_WAITestado é o que um soquete entra quando fecha, para impedir que mensagens cheguem para os aplicativos errados, como poderiam se o soquete fosse reutilizado muito rapidamente e para algumas outras finalidades úteis. Não se preocupe com isso.

(A menos que, é claro, você não esteja executando algo que deva processar tantas operações de RCP. Então, preocupe-se.)

Algo no seu sistema está executando muito RPC (Chamadas de Procedimento Remoto) dentro do seu sistema (observe que a origem e o destino são o host local). Isso costuma ser visto no lockd para montagens NFS, mas você também pode vê-lo em outras chamadas RPC, como rpc.statd ou rpc.spray.

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

tcp_fin_timeoutNÃO controla o TIME_WAITatraso. Você pode ver isso usando ss ou netstat com -o para ver os cronômetros de contagem regressiva:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

mesmo com tcp_fin_timeout definido como 3, a contagem regressiva para TIME_WAIT ainda inicia em 60. No entanto, se você tiver net.ipv4.tcp_tw_reuse definido como 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), o kernel poderá reutilizar soquetes em TIME_WAIT se determinar que não haverá conflitos possíveis no TCP numeração de segmentos.

Eu também tive o mesmo problema. Eu me custou várias horas para descobrir o que está acontecendo. No meu caso, o motivo disso foi que o netstat tenta procurar o nome do host correspondente ao IP (presumo que ele esteja usando a API gethostbyaddr). Eu estava usando uma instalação Linux embutida que não tinha /etc/nsswitch.conf. Para minha surpresa, o problema só existe quando você está realmente executando um netstat -a (descoberto 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 este serviço, o portmapper portmap deve ser contatado para obter a porta para este serviço. Agora o portmapper no meu caso foi contatado via TCP. O portmapper então informa à função libc que esse serviço não existe e a conexão TCP é fechada. Como sabemos, as conexões TCP fechadas entram no estado TIME_WAIT por algum tempo. Portanto, o netstat captura essa conexão ao listar e esta 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 esse problema, crie um /etc/nsswitch.conf que não esteja usando os serviços rpc NIS, ou seja, com o seguinte conteúdo:

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