Comment libérer un port maintenu ouvert par un processus sans issue?

63

Un de mes collègues a récemment rencontré un problème dans lequel un processus supposé être mort était toujours lié à un port réseau, empêchant d'autres processus de se lier à ce port. Plus précisément, netstat -a -bsignalait-on qu'un processus nommé Systemavec le PID 4476 avait le port 60001 ouvert, sauf qu'aucun processus avec le PID 4476 n'existait, du moins pour autant que je sache.

Process Explorer et Task Manager n'ont pas répertorié le PID 4476 (bien qu'un autre processus ait été nommé Systemavec le PID 4, qui possède son propre jeu de connexions TCP n'incluant pas 60001). taskkill /PID 4476a également signalé que le NID 4476 était introuvable.

Existe-t-il un moyen de supprimer ce processus mystérieux du système afin de libérer le port auquel il est actuellement lié? Qu'est-ce qui peut faire que cela se produise? Comment peut-il y avoir des processus dont aucun des gestionnaires de tâches, Explorateur de processus et tâches ne sait rien? Le redémarrage a permis de résoudre le problème, mais j'aimerais savoir s'il existe un moyen de résoudre ce problème sans redémarrer.

— Adam Rosenfield
source

Combien de temps avez-vous attendu pour voir si le port avait été libéré? Dans quel état était la connexion (port)? Établie, fermée, attendue?

— joeqwerty

@ joeqwerty: nous avons attendu au moins 15-20 minutes. Malheureusement, j'oublie dans quel état était la connexion = =.

— Adam Rosenfield

20 minutes semble être un problème. La prochaine fois que cela se produira, lancez netstat et vérifiez l’état de la connexion, cela vous donnera un indice sur ce qui se passe. Comme vous l'avez dit dans la réponse de mfinni, cela peut être dû au blocage de votre logiciel \ service.

— joeqwerty

58

Je sais que c'est un vieux fil, mais au cas où quelqu'un d'autre aurait le même problème, j'avais ...

Ce qui peut arriver est que votre processus a eu un port TCP ouvert quand il est tombé en panne ou s'est arrêté autrement sans le fermer explicitement. Normalement, le système d'exploitation nettoie ce genre de choses, mais seulement lorsque l'enregistrement du processus disparaît. Bien que le processus ne semble plus fonctionner, il existe au moins une chose qui peut en garder une trace, afin d’empêcher la réutilisation de son PID. C'est l'existence d'un processus enfant qui n'est pas détaché du parent.

Si votre programme a généré des processus pendant son exécution, essayez de les tuer. Cela devrait entraîner la libération de son enregistrement de processus et le nettoyage du port TCP. Apparemment, Windows fait cela lorsque l'enregistrement est publié, pas lorsque le processus se termine comme je l'aurais prévu.

— Ogapo
source

1

Merci, bon monsieur. Je ne peux pas croire que cette réponse est si faible, d’autant plus que la requête de Google est remplie de réponses "use TCPView / use netstat & taskkill" qui n’aident pas à résoudre ce problème. Dans mon cas, ce qui nous a aidés était d’exécuter ProcessExplorer et de rechercher tout processus devenu orphelin. Les fermer a résolu le problème.

— Gwiazdorrr

3

Merci pour votre suggestion! Tuer ou manipuler à la main a vraiment résolu le problème.

— Darkthread

Merci!! C'était exactement ce qui m'était arrivé. J'ai tué le processus orphelin et le port a été libéré. Je ne sais pas comment rechercher des processus orphelins à l'aide de l'explorateur de processus, mais je connaissais les noms des processus générés, donc c'était facile à trouver.

— Grezzo

1

Nous avons eu le même problème - et en utilisant Process Explorer, nous avons constaté que le Dr. Watson conservait l'ancien PID. Nous avons recherché (Rechercher) le port que le service tentait d'ouvrir, puis nous avons vu 3 ou 4 entrées pour Dr. Watson et le PID qu'il utilisait. Curieusement, nous n'avons pas eu à TUER implicitement quoi que ce soit. On dirait que ce processus «l'a réveillé» et qu'il a disparu. La prochaine fois que nous avons essayé de redémarrer le service, tout s'est bien passé.

— tresstylez

Un problème similaire peut se produire lors du débogage avec VS. Je joins VS à traiter, et après quelques cycles - la situation décrite se produit, mais aucun de mes processus (y compris les enfants) ne part. Mais tuer "vsjitdebugger" aide.

— Dmitry Azaraev

6

Avez-vous essayé d'utiliser TCPView et de fermer la connexion? Je ne sais pas si cela montrera la connexion dans le scénario que vous décrivez, parce que cela ne m'est jamais arrivé. Mais c'est la seule chose à laquelle je peux penser si cela se reproduisait.

Quel était le processus - était-ce un logiciel commercial ou quelque chose de maison? Il semble que le port 60001 soit utilisé par certains chevaux de Troie. Je me demande s’il s’agissait d’un rootkit ou de quelque chose qui pourrait se cacher du système d’exploitation? Peut-être voudriez-vous donner à cette machine une bonne expérience avec AV, peut-être quelque chose d'un support amorçable.

— Mfinni
source

Non, nous n'avons pas essayé TCPView; Je garderai cela à l'esprit pour l'avenir si cela se reproduisait un jour. Le logiciel est notre logiciel interne qui utilise le port 60001 - je suis presque certain que le processus de maintien du port ouvert était une instance précédente de notre logiciel qui, d'une manière ou d'une autre, n'a pas complètement disparu. Cela a empêché le lancement d'une autre copie du logiciel.

— Adam Rosenfield

Votre application peut définir l'option SO_REUSEADDR du socket sur true avant de le lier. Cela devrait résoudre votre problème (c'est encore plus ou moins obligatoire sur * nix)

— Stephane

3

Ouvrez l'invite de commande en tant qu'administrateur

C: \ WINDOWS \ system32> netstat -ano | findstr: 7895

*** Répétez l'étape 2 jusqu'à ce qu'il n'y ait plus de processus enfant

C: \ WINDOWS \ system32> processus wmic où (ParentProcessId = 1091) obtenir la légende, ProcessId

Sous-titre ProcessId

cmd.exe 1328

2.a. C: \ WINDOWS \ system32> processus wmic où (ParentProcessId = 1328) obtenir la légende, ProcessId

  Caption  ProcessId

  conhost.exe  1128

2.b. Répétez cette opération jusqu'à ce qu'aucun autre processus enfant ne soit trouvé.

- Tuez ensuite tous les processus enfants

C: \ WINDOWS \ system32> taskkill / F / PID 1128 SUCCESS: le processus portant le PID 9500 a été arrêté.

— Srinivas
source

La commande wmic était le seul moyen d'identifier le processus enfant en maintenant nos ports ouverts. Merci beaucoup.

— K Erlandsson

C’est aussi le seul moyen que j’ai trouvé pour régler mon problème. Le processus principal avait disparu et le processus enfant était dans un état suspendu, mais détenait toujours le port TCP avec un état "en écoute". Je vous remercie.

— jeudi

1

J'ai déjà rencontré le même problème plus tôt, la commande netstat -a -n windows m'a donné la liste des ports ouverts avec l'ID de processus. À partir de là, j'ai identifié le numéro de port pour lequel je voulais fermer la connexion, puis j'ai fermé cette connexion à l'aide du logiciel TCPView. Cela a fonctionné pour moi.

— Elavarasi
source

-4

Si vous êtes un utilisateur Windows, suivez les étapes ci-dessous Étape 1: Accédez à ce chemin: Panneau de configuration \ Tous les éléments du panneau de configuration \ Outils d'administration

Étape 2: Cliquez sur les services

Étape 3: Arrêtez les services indésirables s'exécutant sur le port souhaité.

— utilisateur314053
source

-5

ps -ef | grep nomprocessus

tuer les processus liés

tuer -9 pid pid

A travaillé dans mon cas

— java geek
source

6

cette question concerne Windows, pas Linux

— Longneck