Sockets trouvés par lsof mais pas par netstat

Cela peut se produire si vous créez une socket, mais que vous n'avez jamais connecté() ou bind() avec elle. Votre meilleure chance est de stracer (-fF) l'application, puis de croiser les résultats de lsof pour déterminer quelles sont les sockets qui posent problème. Une méthode de débogage supplémentaire : si vous enveloppez vos appels de socket avec des informations de débogage et que vous les écrivez dans /dev/null, elles apparaîtront dans strace sans vous donner des fichiers journaux hilarants.

En utilisant Python, j'ai rencontré le même problème sur les sockets SSL :

• Lorsque j'utilise socket.close(), la socket reste dans l'état CLOSE_WAIT pendant une durée indéterminée.
• quand j'utilise socket.shutdown(), lsof dit "ne peut pas identifier le protocole".

La solution consistait à déballer la couche SSL avant la fermeture :

• origsock = socket.unwrap()
• origsock.close()

Cela ferme les sockets correctement dans mon application.

La première chose que je ferais est d'augmenter la limite de votre descripteur de fichier :

~# vi /etc/sysctl.conf
fs.file-max = 331287

Ensuite, je m'assurerais que votre système est à jour, ce qui inclut toutes les bibliothèques et les serveurs. Il est possible que votre serveur d'application Java ne soit pas à jour (si vous en utilisez un). Il est également possible que votre serveur d'application soit mal configuré, vous devriez regarder votre fichier de configuration et abaisser le niveau de votre connectionTimeout et/ou votre maxKeepAliveRequests (Je ne suis pas sûr du serveur d'application que vous utilisez ou si vous en utilisez un du tout...).

Je ne suis pas sûr de ce que fait cette application, mais si vous ne pensez pas qu'elle nécessite des dizaines de milliers de sockets, alors il s'agit presque certainement d'un problème de sécurité. "fuite de descripteur de fichier" dans votre application Java. Vous devrez peut-être envoyer un rapport de bogue au fournisseur. Dans ce rapport de bogue, vous devez inclure des informations sur la façon de recréer le problème.

Voici quelques moyens de déboguer le problème.

Wireshark (ou twireshark pour le cli) est le meilleur outil pour voir comment ces sockets sont utilisés. Wireshark vous donnera une décomposition du type de trafic envoyé sur le câble. Il est probable que les premières connexions aboutissent, puis qu'elles atteignent la limite des descripteurs de fichiers. Une fois que la limite du descripteur de fichier est atteinte, Wireshark ne détectera plus rien (et netstat est plus efficace à cet égard), mais cela aidera à circonscrire le problème. Il peut y avoir des cas où beaucoup de SYN sortants sont envoyés, mais où aucun SYN/ACK n'est reçu, ce qui fait que beaucoup de connexions tcp sont bloquées dans l'état SYN_WAIT.

Si vous avez accès au code source et que vous connaissez le type de sockets créés (comme en utilisant strace ou simplement en cherchant dans le code), alors vous pouvez ouvrir le projet dans Eclipse (ou un autre IDE) et définir un point d'arrêt au niveau de la fonction qui crée ces sockets. Lorsque le breakpoint est atteint, vous pouvez alors regarder la trace de la pile. Cette fuite de descripteur de fichier peut être une simple boucle infinie ou peut-être que la valeur du délai d'attente de la socket est trop grande. Une autre possibilité est que l'application java n'effectue pas un socket.close() pour nettoyer les connexions. La fermeture est généralement effectuée dans le cadre d'un processus d'évaluation de l'efficacité du système. finely d'un bloc de try/catch (Oui, un socket doit toujours avoir un try/catch en Java ou il ne sera pas construit :). En fin de compte, il est probable que l'application Java ne gère pas correctement ses exceptions IOException.