Come si libera una porta aperta da un processo morto?


63

Un mio collega di recente ha riscontrato un problema in cui un processo apparentemente morto era ancora associato a una porta di rete, impedendo ad altri processi di collegarsi a quella porta. In particolare, netstat -a -briferiva che un processo denominato Systemcon PID 4476 aveva la porta 60001 aperta, tranne per il fatto che non esisteva alcun processo con PID 4476, almeno per quanto potevo dire.

Process Explorer e Task Manager non elencavano il PID 4476 (sebbene esistesse un altro processo denominato Systemcon PID 4, che aveva il proprio set di connessioni TCP che non includeva 60001). taskkill /PID 4476ha anche riferito che PID 4476 non è stato trovato.

C'è un modo per uccidere questo misterioso processo di sistema per liberare la porta a cui è attualmente associato? Cosa può causare ciò? Come possono esserci processi che nessuno dei Task Manager, Process Explorer e taskkill non conosce? Il riavvio è riuscito a risolvere il problema, ma vorrei sapere se esiste un modo per risolvere il problema senza riavviare.


Quanto tempo hai aspettato per vedere se la porta era stata rilasciata? In quale stato si trovava la connessione (porta)? Stabilito, chiuso, Time_Wait?
joeqwerty,

@joeqwerty: abbiamo aspettato almeno 15-20 minuti. Purtroppo ho dimenticato in quale stato si trovava la connessione = /.
Adam Rosenfield,

20 minuti sembra un problema. La prossima volta che si avvia esegui netstat e controlla lo stato della connessione, che ti darà un'idea di cosa sta succedendo. Mentre hai commentato la risposta di mfinni, potrebbe essere il risultato di un crash del tuo software \ servizio.
joeqwerty,

Risposte:


58

So che questo è un vecchio thread, ma nel caso in cui qualcun altro abbia lo stesso problema, ho avuto ...

Ciò che potrebbe accadere è che il tuo processo aveva una porta TCP aperta quando si è arrestata in modo anomalo o in altro modo è stata chiusa senza chiuderla esplicitamente. Normalmente il sistema operativo pulisce questo genere di cose, ma solo quando il record del processo scompare. Mentre il processo potrebbe non sembrare più in esecuzione, esiste almeno una cosa che può tenerne traccia, al fine di impedire il riutilizzo del suo PID. Questa è l'esistenza di un processo figlio che non è distaccato dal genitore.

Se il tuo programma ha generato dei processi mentre era in esecuzione, prova a ucciderli. Ciò dovrebbe causare la liberazione del relativo record di processo e la pulizia della porta TCP. Apparentemente Windows lo fa quando il record viene rilasciato non quando il processo termina come mi sarei aspettato.


1
Grazie, buon signore. Non posso credere che questa risposta sia così bassa, soprattutto perché la query di Google è piena di risposte "usa TCPView / usa netstat & taskkill" che non aiutano in questo caso. Nel mio caso ciò che ha aiutato era l'esecuzione di ProcessExplorer e la ricerca di qualsiasi processo che fosse rimasto orfano. La loro chiusura ha risolto il problema.
gwiazdorrr,

3
Grazie per il tuo suggerimento !! L'omicidio o il processo manuale risolve davvero il problema.
Darkthread

Grazie!! Questo era esattamente quello che mi era successo. Ho ucciso il processo orfano e il porto è stato rilasciato. Non sono sicuro di come cercare i processi orfani utilizzando Process Explorer, ma conoscevo i nomi dei processi generati, quindi era facile da trovare.
Grezzo,

1
Abbiamo avuto lo stesso problema e l'utilizzo di Process Explorer ha visto che il Dr. Watson stava trattenendo il vecchio PID. Abbiamo cercato (Trova) la porta che il servizio stava tentando di aprire, quindi abbiamo visto 3-4 voci per il Dr. Watson e il PID che stava utilizzando. Stranamente, non abbiamo dovuto uccidere implicitamente nulla. Sembra che quel processo "lo abbia svegliato" e sia scomparso. La prossima volta che abbiamo provato a riavviare il servizio, è andato tutto bene.
tresstylez,

Problema simile può verificarsi durante il debug con VS. Allego VS al processo e, dopo alcuni cicli, si verifica la situazione descritta, ma nessun processo (compresi i bambini) se ne va. Ma uccidere "vsjitdebugger" aiuta.
Dmitry Azaraev,

6

Hai provato a utilizzare TCPView e a chiudere la connessione? Non so se mostrerà la connessione nello scenario che stai descrivendo, perché non mi è mai successo. Ma è l'unica cosa a cui riesco a pensare se questo accade di nuovo.

Qual è stato il processo: è stato un software commerciale o qualcosa di nativo? Sembra che la porta 60001 sia utilizzata da alcuni trojan: mi chiedo se avrebbe potuto essere un rootkit o qualcosa che potrebbe nascondersi dal sistema operativo? Potrebbe voler dare una buona volta a quella macchina con AV, forse qualcosa dal supporto di avvio.


No, non abbiamo provato TCPView; Lo terrò a mente per il futuro se mai dovesse succedere di nuovo. Il software è il nostro software interno che utilizza la porta 60001 - Sono quasi certo che il processo di apertura della porta fosse una precedente istanza del nostro software che in qualche modo non è morto del tutto. Ciò ha impedito l'avvio di un'altra copia del software.
Adam Rosenfield,

L'applicazione può impostare su SO_REUSEADDR l'opzione del socket su true prima di associarlo. Questo dovrebbe risolvere il tuo problema (è ancora più o meno obbligatorio su * nix)
Stephane

3

Apri il prompt dei comandi come amministratore

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

*** Ripetere il passaggio 2 fino a quando non ci sono più processi figlio

  1. C: \ WINDOWS \ system32> processo wmic in cui (ParentProcessId = 1091) ottiene Caption, ProcessId

    ID processo di didascalia

    cmd.exe 1328

2.a. C: \ WINDOWS \ system32> processo wmic in cui (ParentProcessId = 1328) ottiene Caption, ProcessId

  Caption  ProcessId

  conhost.exe  1128

2.b. ripetere questo fino a quando non vengono trovati altri processi figlio

- Quindi uccidi tutti i processi figlio

  1. C: \ WINDOWS \ system32> taskkill / F / PID 1128 SUCCESSO: il processo con PID 9500 è stato terminato.

Il comando wmic era l'unico modo in cui siamo riusciti a identificare il processo figlio mantenendo effettivamente aperte le nostre porte. Grazie molto.
K Erlandsson,

Questo è stato anche l'unico modo che ho trovato per risolvere il mio problema. Il processo principale era sparito e il processo figlio era in uno stato sospeso, ma manteneva ancora la porta TCP con uno stato "Ascolto". Grazie.
Gui

1

Ho già affrontato lo stesso problema in precedenza, netstat -a -n il comando windows mi ha dato l'elenco delle porte aperte con ID processo. Da quello ho preso il numero di porta che volevo chiudere la connessione e poi ho chiuso quella connessione utilizzando il software TCPView. Questo ha funzionato per me.


-4

Se sei un utente Windows, segui i passaggi seguenti: Passaggio 1: vai a questo percorso: Pannello di controllo \ Tutti gli elementi del pannello di controllo \ Strumenti di amministrazione

Step2: fare clic su servizi

Passaggio 3: interrompere i servizi indesiderati in esecuzione sulla porta desiderata.


-5

ps -ef | grep processname

uccidere i processi correlati

uccidi -9 pid pid

Ha funzionato nel mio caso


6
questa domanda riguarda Windows, non Linux
collo lungo
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.