web-dev-qa-db-fra.com

Connexions orphelines dans l'état CLOSE_WAIT

J'ai une machine SLES qui accumule 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'ai 3037 de eux, mais il é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 pas de PID associés 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 logique, car ces valeurs sont par défaut , par 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.

linuxnetworkingtcp
30
pboin

Non, il n'y a pas de délai d'expiration pour CLOSE_WAIT. Je pense que c'est ce que le off signifie dans votre sortie.

Sortir de CLOSE_WAIT, l'application doit fermer explicitement le socket (ou quitter).

Voir Comment briser CLOSE_WAIT .

Si netstat 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)
16
Mikel

CLOSE_WAIT indique que le client ferme la connexion mais que l'application ne l'a pas encore fermée, ou 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 CLOSE

pour 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 nfs ou 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. Ajoutez des ports fixes pour NFS à /etc/services
    rpc.statd-bc 32763/udp # RCP statd broadcast 
 rpc.statd-bc 32763/tcp 
 rpc.statd 32764/udp # RCP statd écouter 
 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. Configurez statd pour utiliser les options --port 32763 --outgoing-port 32764
  4. Configurez rpcmountd pour utiliser l'option --port 32765
  5. Arrêtez et redémarrez les services NFS et RPC.
10
BillThor