Perché Google Chrome ascolta sulla porta 8000?

Occasionalmente quando si avvia un server di sviluppo (di nuovo), morirà con il messaggio che la porta 8000 è già in uso.

In esecuzione

$ lsof -n -i4TCP:8000 | grep LISTEN

quindi rivela

Google    18638  <user>  450u  IPv6 0x9b020d3ae3f0d7e9      0t0  TCP *:irdmi (LISTEN)

L'unica soluzione al momento della scrittura è il riavvio completo di Chrome. C'è una spiegazione per questa apertura di una porta (forse un plugin) o è correlata al server di sviluppo in esecuzione su 0.0.0.0:8000?

macos google-chrome ipv6

— linea-o
fonte

Qual è la natura di questo server di sviluppo e cosa ha a che fare con Chrome?

— jjlin,

Questo è probabilmente qualcosa a che fare con le funzionalità di debug remoto di Chrome , prova ad andare a chrome://inspectvedere se questo ti dà qualche indizio.

— Tom,

Ti suggerisco di verificare se si tratta effettivamente di Google Chrome controllando il processo ps aux | grep 18638.

— fetzig,

2018, e sembra che l'attuale versione di Chrome non ascolti sulla porta (Versione 70.0.3538.110 (build ufficiale) (64 bit) MacOS)

— The Matt,

Risposte:

Credo che abbia a che fare con l'ascolto di dispositivi esterni per il casting. Potresti provare a disabilitare i flag che contengono "media". Non sono stato in grado di restringere quale bandiera stia effettivamente ascoltando. chrome: // flags / # hardware-media-chiave di manipolazione. Prova a cercare contenuti multimediali

— Lucertola
fonte

-1

Se si dispone di un processo in ascolto su una porta e si interrompe tale processo, non si annullerà immediatamente tale porta. Penso che l'impostazione predefinita sulla maggior parte dei sistemi Linux sia un'attesa di 5 minuti. Controlla la pagina man del socket (7) e cerca SO_REUSEADDR.

— Johnathan Andersen
fonte

Questo non sembra rispondere alla domanda sul perché Chrome stia ascoltando su quella porta. Si prega di modificare il tuo post in modo che sia chiaro come si riferisce alla domanda.

— Ben N,