Dlaczego Google Chrome nasłuchuje na porcie 8000?

Czasami przy ponownym uruchomieniu serwera programistycznego (ponownie) umiera z komunikatem, że port 8000 jest już w użyciu.

Bieganie

$ lsof -n -i4TCP:8000 | grep LISTEN

następnie ujawnia

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

Jedynym obejściem w chwili pisania tego tekstu jest całkowite ponowne uruchomienie Chrome. Czy istnieje wyjaśnienie dla tego otwarcia portu (być może wtyczki), czy jest to związane z serwerem programistycznym, który działał w wersji 0.0.0.0:8000?

macos google-chrome ipv6

— linia-o
źródło

Jaka jest natura tego serwera programistycznego i co ma on wspólnego z Chrome?

— jjlin

Być może ma to związek z funkcjami zdalnego debugowania w Chrome. Spróbuj chrome://inspectsprawdzić, czy daje to jakieś wskazówki.

— Tom

Sugeruję sprawdzenie, czy to rzeczywiście Google Chrome, sprawdzając proces ps aux | grep 18638.

— fetzig

2018 i wygląda na to, że obecna wersja chrome nie nasłuchuje na porcie (wersja 70.0.3538.110 (oficjalna wersja) (64-bitowy) MacOS)

— Matt

Odpowiedzi:

Uważam, że ma to związek ze słuchaniem zewnętrznych urządzeń do castingu. Możesz spróbować wyłączyć flagi zawierające „media”. Nie byłem w stanie zawęzić, która flaga faktycznie nasłuchuje. chrome: // flags / # hardware-media-key-handling. Spróbuj wyszukać multimedia

— Jaszczurka
źródło

-1

Jeśli masz proces nasłuchujący na porcie i zabijesz ten proces, nie spowoduje to natychmiastowego cofnięcia wiązania tego portu. Myślę, że domyślnie w większości systemów Linux to 5 minut oczekiwania. Sprawdź stronę podręcznika gniazda (7) i poszukaj SO_REUSEADDR.

— Johnathan Andersen
źródło

To nie wydaje się odpowiadać na pytanie, dlaczego Chrome nasłuchuje na tym porcie. Proszę edytować swój post więc to jasne, w jaki sposób odnosi się do tej kwestii.

— Ben N