29 votos

Una enorme cantidad de conexiones TIME_WAIT dice que netstat

Vale, esto me da escalofríos. Veo unos 1500-2500 de estos:

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

Ese número está cambiando rápidamente.

Tengo una configuración de iptables bastante apretada, así que no tengo ni idea de qué puede causar esto. ¿Alguna idea?

Gracias,

Tamas

Edición: Salida 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   -

24voto

Andrew Redd Puntos 118

Como han mencionado otros, tener algunas conexiones en TIME_WAIT es una parte normal de la conexión TCP. Se puede ver el intervalo examinando /proc/sys/net/ipv4/tcp_fin_timeout:

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

Y cambiarlo modificando ese valor:

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

O permanentemente añadiéndolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Además, si no usas el servicio RPC o NFS, puedes simplemente apagarlo:

/etc/init.d/nfsd stop

Y apagarlo completamente

chkconfig nfsd off

20voto

David Pashley Puntos 17011

TIME_WAIT es normal. Es un estado después de que un enchufe se ha cerrado, usado por el núcleo para llevar un registro de los paquetes que se pueden haber perdido y que llegaron tarde a la fiesta. Un alto número de conexiones TIME_WAIT es un síntoma de tener muchas conexiones de corta duración, no es nada de lo que preocuparse.

5voto

Corin Blaikie Puntos 6223

No es importante. Todo lo que significa es que estás abriendo y cerrando un montón de conexiones TCP RCP de Sun (1500-2500 de ellas cada 2-4 minutos). El TIME_WAIT es lo que un enchufe entra cuando se cierra, para evitar que lleguen mensajes para las aplicaciones equivocadas como podrían hacerlo si el enchufe se reutilizara demasiado rápido, y para un par de otros propósitos útiles. No se preocupe por ello.

(A menos, por supuesto, que no esté ejecutando nada que deba procesar tantas operaciones de RCP. Entonces, preocúpate).

4voto

Jake Wharton Puntos 160

Algo en su sistema está haciendo un montón de RPC (Remote Procedure Calls) dentro de su sistema (note que tanto la fuente como el destino es localhost). Eso se ve a menudo para los montajes NFS, pero también se puede ver para otras llamadas RPC como rpc.statd o rpc.spray.

Podrías intentar usar "lsof -i" para ver quién tiene esos enchufes abiertos y ver qué está haciendo. Probablemente sea inofensivo.

1voto

leecher Puntos 1

Yo también tuve el mismo problema. Me costó varias horas averiguar lo que está pasando. En mi caso, el motivo fue que netstat intenta buscar el nombre de host correspondiente a la IP (asumo que está usando la API gethostbyaddr). Estaba usando una instalación de Linux embebida que no tenía /etc/nsswitch.conf. Para mi sorpresa, el problema sólo existe cuando se está haciendo un netstat -a (lo descubrí ejecutando el portmap en modo verborreico y de depuración).

Ahora lo que pasó fue lo siguiente: Por defecto, las funciones de búsqueda también intentan contactar con el demonio ypbind (Páginas Amarillas del Sol, también conocidas como NIS) para buscar un nombre de host. Para consultar este servicio, hay que contactar con el portmapper portmap para obtener el puerto para este servicio. Ahora el portmapper en mi caso fue contactado a través de TCP. El portmapper entonces le dice a la función libc que no existe tal servicio y la conexión TCP se cierra. Como sabemos, las conexiones TCP cerradas entran en un estado TIME_WAIT durante algún tiempo. Así que netstat atrapa esta conexión cuando se lista y esta nueva línea con una nueva IP emite una nueva petición que genera una nueva conexión en estado TIME_WAIT y así sucesivamente...

Para resolver este problema, cree un /etc/nsswitch.conf que no utilice los servicios NIS del rpc, es decir, con el siguiente contenido:

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

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: