web-dev-qa-db-fra.com

Une énorme quantité de connexions TIME_WAIT indique netstat

D'accord, cela me fait flipper - j'en vois environ 1500-2500:

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

Ce nombre évolue rapidement.

J'ai une configuration iptables assez serrée, donc je n'ai aucune idée de ce qui peut provoquer cela. des idées?

Merci,

Tamas

Edit: Sortie 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   -               
28
KTamas

EDIT: tcp_fin_timeout NE FAIT PAS contrôle la durée TIME_WAIT, il est codé en dur à 60s

Comme mentionné par d'autres, avoir des connexions dans TIME_WAIT est une partie normale de la connexion TCP. Vous pouvez voir l'intervalle en examinant /proc/sys/net/ipv4/tcp_fin_timeout:

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

Et changez-le en modifiant cette valeur:

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

Ou de façon permanente en l'ajoutant à /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

De plus, si vous n'utilisez pas le service RPC ou NFS, vous pouvez simplement le désactiver:

/etc/init.d/nfsd stop

Et éteignez-le complètement

chkconfig nfsd off
22
Brandon

TIME_WAIT est normal. C'est un état après la fermeture d'un socket, utilisé par le noyau pour garder une trace des paquets qui peuvent avoir été perdus et arrivés en retard à la fête. Un nombre élevé de connexions TIME_WAIT est un symptôme d'avoir beaucoup de connexions de courte durée, pas de quoi s'inquiéter.

16
David Pashley

Ce n'est pas important. Tout ce que cela signifie, c'est que vous ouvrez et fermez beaucoup de connexions Sun RCP TCP (1500-2500 d'entre elles toutes les 2-4 minutes). Le TIME_WAIT l'état est ce dans quoi un socket entre quand il se ferme, pour empêcher les messages d'arriver pour les mauvaises applications comme ils le feraient si le socket était réutilisé trop rapidement, et pour quelques autres fins utiles. Ne t'en fais pas.

(À moins, bien sûr, que vous n'exécutiez rien qui devrait traiter autant d'opérations RCP. Alors, inquiétez-vous.)

5
chaos

Quelque chose sur votre système fait beaucoup de RPC (appels de procédure à distance) dans votre système (notez que la source et la destination sont localhost). Cela est souvent vu pour lockd pour les montages NFS, mais vous pouvez également le voir pour d'autres appels RPC comme rpc.statd ou rpc.spray.

Vous pouvez essayer d'utiliser "lsof -i" pour voir qui a ces sockets ouverts et voir ce qui le fait. C'est probablement inoffensif.

4
Paul Tomblin

tcp_fin_timeout ne contrôle PAS TIME_WAIT retard. Vous pouvez le voir en utilisant ss ou netstat avec -o pour voir les minuteries de compte à rebours:

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)

même avec tcp_fin_timeout défini sur 3, le compte à rebours pour TIME_WAIT commence toujours à 60. Cependant, si net.ipv4.tcp_tw_reuse est défini sur 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), le noyau peut réutiliser les sockets dans TIME_WAIT s'il détermine qu'il n'y aura aucun conflit possible dans la numérotation des segments TCP.

2
Greg Bray

J'ai aussi eu le même problème. J'ai mis plusieurs heures à découvrir ce qui se passe. Dans mon cas, la raison en est que netstat essaie de rechercher le nom d'hôte correspondant à l'IP (je suppose qu'il utilise l'API gethostbyaddr). J'utilisais une installation Linux intégrée qui n'avait pas /etc/nsswitch.conf. À ma grande surprise, le problème n'existe que lorsque vous effectuez réellement un netstat -a (découvert cela en exécutant portmap en mode verbeux et débogage).

Maintenant, ce qui s'est passé est le suivant: Par défaut, les fonctions de recherche essaient également de contacter le démon ypbind (Sun Yellow Pages, également connu sous le nom de NIS) pour demander un nom d'hôte. Pour interroger ce service, le portmapper portmap doit être contacté pour obtenir le port de ce service. Maintenant, le portmapper dans mon cas a été contacté via TCP. Le portmapper indique ensuite à la fonction libc qu'aucun service de ce type n'existe et que la connexion TCP est fermée. Comme nous le savons, les connexions fermées TCP entrent dans un état TIME_WAIT pour certains Ainsi, netstat intercepte cette connexion lors de l'inscription et cette nouvelle ligne avec une nouvelle adresse IP émet une nouvelle demande qui génère une nouvelle connexion dans l'état TIME_WAIT et ainsi de suite ...

Afin de résoudre ce problème, créez un /etc/nsswitch.conf qui n'utilise pas les services NPC rpc, c'est-à-dire avec le contenu suivant:

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