No tengo idea de qué está escuchando en el puerto 80 en OS X

Estoy en OSX Mountain Lion 10.8.3, y recientemente he reiniciado mi Mac.

Quiero iniciar un servicio (como Apache en el puerto 80), pero ya está sucediendo algo con el puerto 80:

telnet localhost 80

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

Espera, te escucho decir, puedes encontrar eso con lsof o netstat. Excepto que no hay nada allí.

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

*comes back blank*

lsof -i :80 | grep LISTEN

*comes back blank

Entonces, por lo que sé sobre los sistemas Unix, ¿creo que esta debe ser una regla de reenvío de paquetes? Es decir, los paquetes se reenvían desde el puerto entrante 80 a otra cosa, que está escuchando en ese servicio.

ipfw show

65535 0 0 allow ip from any to any

Hmm, nada inusual allí

pfctl -s nat

No ALTQ support in kernel
ALTQ related functions disabled

Nada inusual allí

Mi pregunta es, ¿cómo puedo mostrar las reglas de reenvío de paquetes ... En Linux, podría hacer iptables -L -t NAT o iptables -L. O, alternativamente, ¿pueden los expertos de OSX ayudarme a diagnosticar este problema?

— Geoff
fuente

No es una respuesta directa a su pregunta interesante, pero: ¿qué pasa si su navegador apunta a http: // localhost ?

— Arjan

El lsofgrep que usaste volvería en blanco; los números de puerto se asignan a los /etc/servicesnombres. Prueba lsof -i | grep http...

— Nevin Williams

En realidad, el mapeo / etc / services no es un problema si usa el -i :portformato, solo si lo hace grep. Lo que será un problema es que lsofnecesita privilegios de root para ver los procesos de otros usuarios, por lo que debe usar sudo lsof -i :80(y lo probaría sin el grep, solo para asegurarme ...)

— Gordon Davisson

Hola a todos, gracias por las sugerencias hasta ahora, pero no ha aparecido nada, incluso como root, y sin greps, no hay nada en la lista que escuche realmente el puerto 80.

— geoff

¿Intentó lsof -i :80mientras estaba conectado en esa sesión Telnet? ¿Y además de intentar http: // localhost / , tal vez escribir algo en ese indicador de Telnet revela algo ...? (Una vez más, lo sé: incluso si lo descubres de esa manera, no sería la respuesta a tu pregunta ...)

— Arjan

Respuestas:

Debe ejecutar estos comandos rootpara mostrar los procesos de otros usuarios, por ejemplo:

sudo lsof -i ':80'

Mac OS X incluye un servidor web Apache que se puede controlar usando apachectlcomo root. Por lo general, se inicia mediante launchd, el archivo de configuración correspondiente es /System/Library/LaunchAgents/org.apache.httpd.plist. Si no es este Apache que se ejecuta en el puerto 80, probablemente se lance , la implementación de Apple de un administrador de demonios. De acuerdo con Wikipedia :

Cuando launchd escanea a través de las listas de trabajos en el momento del arranque, se reserva y escucha en todos los puertos solicitados por esos trabajos. Si así se indica en el plist por la tecla "OnDemand", el demonio no se carga en ese momento. Por el contrario, launchd escuchará en el puerto, iniciará el demonio cuando sea necesario y lo cerrará cuando no lo esté. Después de cargar un demonio, launchd lo rastreará y se asegurará de que se esté ejecutando si es necesario.

— Daniel Beck
fuente

Así que supongo que mi idea era correcto que sudo lsof -i ':80' la fuerza en realidad no devuelve nada, a menos que se corre de que mientras está conectado en la sesión Telnet? Pero incluso sin esos comandos, http: // localhost / , probablemente todavía han mostrado alguna página de bienvenida de Apache?

— Arjan

(Creo que su respuesta es probablemente la solución; simplemente no coincide con todos los comentarios del OP.)

— Arjan

Gracias por esta brillante respuesta. Ahora he logrado resolverlo: 1. Hubo un error en httpd.conf, por lo que sudo apachectl start no estaba iniciando apache. 2. Pero launchd estaba escuchando en el puerto 80, listo para reenviar solicitudes a un servidor inexistente. 3. Sin embargo, launchd no estaba escuchando en el sentido convencional, es decir, los resultados de sudo lsof -i: 80 estaba en blanco, del mismo modo para netstat 4. Supongo que launchd hace algo de magia como xinetd en que no escucha oficialmente un puerto, pero de alguna manera logra permitir conexiones al puerto sobornando el núcleo.

— Geoff

Para mí, lo que resolvió el problema se estaba ejecutando sudo apachectl stopen la terminal.

— MikeiLL

Esto no funcionó para mí, pero esta versión no mostrar lo que estaba en funcionamiento (OS High Sierra 10.13.6) sudo lsof -i -P | grep -i "80"de superuser.com/questions/984919/...

— RoboBear

Solo para aclarar la respuesta real en caso de que los usuarios estén buscando esto.

launchd escanea el /System/Library/LaunchDaemons/arranque y funciona a partir de org.apache.httpd.plisteso cuando apache se inicia, necesita reenviar el puerto 80 a él.
sudo apachectl start fue hecho
Sin embargo, hubo un error en el httpd.confarchivo que significa que apache no se inició, aunque esto no se informó a través del apachectlcomando.
Launchd decidió escuchar en el puerto 80 ya que pensaba que Apache estaba activo.
Pero el contenido de cualquier solicitud HTTP resultó en un cierre inmediato de la conexión.
sudo lsof -i :80 no dio respuestas
sudo netstat -an | grep LISTEN no arrojó respuestas para el puerto 80
no había información hasta donde pude ver en ninguna herramienta de diagnóstico que mostrara que el puerto 80 estaba en uso o escuchando.
arreglar httpd.conf de apache y reiniciar apache con éxito para que httpd estuviera en la tabla ps, llevó a que las solicitudes HTTP tuvieran éxito.
Por lo tanto, estaba equivocando que no podía ejecutar apache porque ya había algo escuchando en el puerto 80, en lugar de que apache conf fuera la causa.

— Geoff
fuente

Entonces, ¿qué estaba mal con httpd.conf? Tengo este problema ahora y no estoy seguro de cómo proceder según su respuesta aquí ... ??

— Drew Angell

Acabo de encontrarme con este mismo problema con el antivirus OSX El Capitan y Avast. sudo lsof -i ':80'mostró una conexión a 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)

Tuve que

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

para evitar que lo use el puerto 80.

— espiar
fuente