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 -
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
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.
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.)
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.
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.
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