Non ho idea di cosa stia ascoltando sulla porta 80 in OS X

Sono su OSX Mountain Lion 10.8.3 e ho appena riavviato il mio Mac.

Voglio avviare un servizio (come Apache sulla porta 80), ma c'è già qualcosa da fare con la porta 80:

telnet localhost 80

Trying ::1...
Connected to localhost.
Escape character is '^]'.

Aspetta, ti sento dire, puoi trovarlo con lsof o netstat. Tranne che non c'è niente lì

netstat -an | grep LISTEN | grep '\.80'

*comes back blank*

lsof -i :80 | grep LISTEN

*comes back blank

Quindi, da quello che so sui sistemi unix, immagino che questa debba essere una regola di inoltro di pacchetti allora? Vale a dire che i pacchetti vengono inoltrati dalla porta di ingresso 80 a qualcos'altro, che è in ascolto su quel servizio.

ipfw show

65535 0 0 allow ip from any to any

Hmm, niente di insolito lì

pfctl -s nat

No ALTQ support in kernel
ALTQ related functions disabled

Niente di insolito lì

La mia domanda è: come posso visualizzare le regole di inoltro dei pacchetti ... Su Linux potrei semplicemente fare iptables -L -t NAT o iptables -L. O in alternativa, alcuni esperti OSX possono aiutarmi a diagnosticare questo problema?

— Geoff
fonte

Non una risposta diretta alla tua domanda interessante, ma: cosa succede se si punta il browser su http: // localhost ?

— Arjan,

Il lsofgrep che hai usato sarebbe tornato vuoto; i numeri di porta sono associati ai /etc/servicesnomi. Prova lsof -i | grep http...

— Nevin Williams,

In realtà, il mapping / etc / services non è un problema se si utilizza il -i :portformato, solo se si grep. Quale sarà un problema è che ha lsofbisogno dei privilegi di root per vedere i processi di altri utenti, quindi dovresti usarlo sudo lsof -i :80(e lo proverei senza grep, solo per essere sicuro ...)

— Gordon Davisson,

Ciao a tutti, grazie per i suggerimenti finora, ma non ha mostrato nulla - anche come root, e senza greps, non c'è nulla di elencato come effettivamente ascoltando la porta 80.

— geoff

Hai provato lsof -i :80mentre eri ancora connesso in quella sessione Telnet? E a parte provare http: // localhost / , forse digitare qualcosa al prompt di Telnet rivela qualcosa ...? (Ancora una volta, lo so: anche se lo capissi in quel modo, non sarebbe la risposta alla tua domanda ...)

— Arjan,

Risposte:

È necessario eseguire questi comandi rootper mostrare i processi di altri utenti, ad esempio:

sudo lsof -i ':80'

Mac OS X include un server Web Apache che può essere controllato utilizzando apachectlas root. Di solito viene avviato tramite launchd, il file di configurazione corrispondente è /System/Library/LaunchAgents/org.apache.httpd.plist. Se non è questo Apache in esecuzione sulla porta 80, è probabilmente lanciato , l'implementazione di Apple di un daemon manager. Secondo Wikipedia :

Quando launchd esegue la scansione dei piani di lavoro all'avvio, si riserva e ascolta su tutte le porte richieste da tali lavori. Se indicato nel plist dalla chiave "OnDemand", il demone non viene effettivamente caricato al momento. Piuttosto, launchd ascolterà sulla porta, avvierà il demone quando necessario e lo spegnerà quando non lo è. Dopo aver caricato un demone, launchd ne terrà traccia e si assicurerà che sia in esecuzione se necessario.

— Daniel Beck
fonte

Quindi suppongo che la mia idea fosse giusta, che sudo lsof -i ':80' potrebbe non restituire nulla, a meno che uno non lo esegua mentre è connesso nella sessione Telnet? Ma anche senza quei comandi, http: // localhost / probabilmente avrebbe comunque mostrato qualche pagina di benvenuto di Apache?

— Arjan,

(Credo che la tua risposta sia probabilmente la soluzione; semplicemente non corrisponde a tutti i commenti del PO.)

— Arjan

Grazie per questa brillante risposta. Ora sono riuscito a risolverlo: 1. Si è verificato un errore in httpd.conf, quindi sudo apachectl start non ha avviato apache. 2. Ma launchd era in ascolto sulla porta 80, pronto a inoltrare richieste a un server inesistente. 3. Comunque launchd non stava ascoltando in senso convenzionale - cioè - i risultati di sudo lsof -i: 80 era vuoto, allo stesso modo per netstat 4. Immagino che launchd faccia un po 'di magia come xinetd in quanto non lo ascolta ufficialmente una porta, ma in qualche modo riesce a consentire connessioni alla porta corrompendo il kernel.

— geoff,

Per me ciò che ha risolto il problema era in esecuzione sudo apachectl stopnel terminale.

— MikeiLL,

Questo non ha funzionato per me, ma questa versione ha mostrare ciò che era in esecuzione (OS High Sierra 10.13.6) sudo lsof -i -P | grep -i "80"da superuser.com/questions/984919/...

— RoboBear

Giusto per chiarire la risposta effettiva nel caso in cui gli utenti lo stiano cercando.

launchd esegue la scansione /System/Library/LaunchDaemons/all'avvio ed esegue da org.apache.httpd.plistesso all'avvio di Apache deve inoltrare la porta 80 su di esso.
sudo apachectl start è stato fatto
Tuttavia, si è verificato un errore nel httpd.conffile che significa che apache non è stato avviato, sebbene ciò non sia stato segnalato tramite il apachectlcomando.
Launchd ha deciso di ascoltare sulla porta 80 poiché pensava che Apache fosse attivo.
Ma il contenuto di qualsiasi richiesta HTTP ha comportato una chiusura immediata della connessione.
sudo lsof -i :80 non ha prodotto risposte
sudo netstat -an | grep LISTEN non ha prodotto risposte per la porta 80
non c'erano informazioni per quanto potessi dire in alcuno strumento diagnostico che dimostrasse che la porta 80 era in uso o in ascolto.
riparare httpd.conf di apache e riavviare apache con successo in modo che httpd fosse nella tabella ps, ha portato le richieste HTTP ad avere successo.
Stavo quindi sbagliando che non potevo eseguire apache perché c'era già qualcosa in ascolto sulla porta 80, piuttosto che la causa

— Geoff
fonte

Quindi cosa c'era che non andava in httpd.conf? Sto riscontrando questo problema ora e non sono sicuro di come procedere in base alla tua risposta qui .. ??

— Ha disegnato Angell il

Ho appena riscontrato questo stesso problema con OSX El Capitan e Avast antivirus. sudo lsof -i ':80'ha mostrato una connessione con avast.com.

me@destop ~|master$ sudo lsof -i ':80'
Password:
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
com.avast 7964 root   58u  IPv4 0xc4c1bba31fcc2c7f      0t0  TCP 192.168.100.111:52381->mia04-004.ff.avast.com:http (ESTABLISHED)

Dovevo

disinstallare Avast con /Applications/Uninstall Avast.app
sudo rm -rf "/Library/Application Support/Avast" "/Applications/Avast Business Security.app" "/Applications/Uninstall Avast.app"
ricomincia

per impedirgli di usarlo porta 80.

— spyle
fonte