Connexions orphelines dans l'état CLOSE_WAIT

J'ai une machine SLES qui accumule les connexions TCP dans un état CLOSE_WAIT pour ce qui semble être éternel. Ces descripteurs finissent par aspirer toute la mémoire disponible. Pour le moment, j'en ai 3037, mais c'était beaucoup plus élevé avant un redémarrage rapide récemment.

Ce qui est intéressant, c'est qu'ils ne proviennent pas de connexions à des ports locaux auxquels je m'attends à avoir des processus d'écoute. Ils n'ont aucun PID associé, et leurs temporisateurs semblent avoir expiré.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

Je ne suis pas une ceinture noire en ce qui concerne la pile TCP ou la mise en réseau du noyau, mais la configuration TCP semble raisonnable, car ces valeurs sont par défaut, selon la page de manuel:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Alors qu'est-ce qui donne? Si les temporisateurs ont expiré, la pile ne devrait-elle pas effacer automatiquement ces éléments? Je me donne effectivement un DoS à long terme à mesure que ces choses s'accumulent.

Non, il n'y a pas de délai d'attente CLOSE_WAIT. Je pense que c'est ce que offsignifie votre sortie.

Pour en sortir CLOSE_WAIT, l'application doit fermer explicitement le socket (ou quitter).

Voir Comment briser CLOSE_WAIT .

Si netstats'affiche -dans la colonne de processus:

• exécutez-vous avec les privilèges et capacités appropriés (par exemple en tant que root)?
• il peut s'agir de processus du noyau (par exemple nfsd)

CLOSE_WAITindique que le client ferme la connexion mais que l'application ne l'a pas encore fermée, ou que le client ne l'est pas. Vous devez identifier le ou les programmes qui rencontrent ce problème. Essayez d'utiliser netstat -tonp 2>&1 | grep CLOSEpour déterminer quels programmes détiennent les connexions.

Si aucun programme n'est répertorié, le service est fourni par le noyau. Il s'agit probablement de services RPC tels que nfsou rpc.lockd. Les services d'écoute du noyau peuvent être répertoriés avec netstat -lntp 2>&1 | grep -- -.

À moins que les services RPC n'aient été liés à des ports fixes, ils se lieront à des ports éphémères comme vos connexions semblent le montrer. Vous pouvez également vouloir vérifier les processus et les montages sur l'autre serveur.

Vous pouvez peut-être lier vos services NFS à des ports fixes en procédant comme suit:

1. Sélectionnez quatre ports inutilisés pour NFS (32763-32766 utilisé ici)
2. Ajouter des ports fixes pour NFS à /etc/services

   rpc.statd-bc 32763 / udp # RCP diffusion statd
   rpc.statd-bc 32763 / tcp
   rpc.statd 32764 / udp # RCP statd listen
   rpc.statd 32764 / tcp
   rpc.mountd 32765 / udp # RPC mountd
   rpc.mountd 32765 / tcp
   rpc.lockd 32766 / udp # RPC lockd / nlockmgr
   rpc.lockd 32766 / tcp

3. Configurer statd pour utiliser les options --port 32763 --outgoing-port 32764
4. Configurer rpcmountd pour utiliser l'option --port 32765
5. Arrêtez et redémarrez les services NFS et RPC.