Aucune idée de ce que vous écoutez sur le port 80 sous OS X

Je suis sur OSX Mountain Lion 10.8.3 et j'ai récemment redémarré mon Mac.

Je souhaite démarrer un service (comme Apache sur le port 80), mais il se passe déjà quelque chose avec le port 80:

telnet localhost 80

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

Attendez, je vous entends dire, vous pouvez trouver cela avec lsof ou netstat. Sauf qu'il n'y a rien là

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

*comes back blank*

lsof -i :80 | grep LISTEN

*comes back blank

Donc, d'après ce que je sais des systèmes Unix, je suppose que cela doit alors être une règle de transmission de paquets? Par exemple, des paquets sont transférés du port entrant 80 vers un autre moyen, qui écoute sur ce service.

ipfw show

65535 0 0 allow ip from any to any

Hmm, rien d'inhabituel là

pfctl -s nat

No ALTQ support in kernel
ALTQ related functions disabled

Rien d'inhabituel là-bas

Ma question est la suivante: comment puis-je afficher les règles de transfert de paquets? Sous Linux, je peux simplement faire iptables -L -t NAT ou iptables -L. Ou encore, des experts en OSX peuvent-ils m'aider à diagnostiquer ce problème?

— geoff
source

Pas une réponse directe à votre question intéressante, mais: que se passe-t-il si vous pointez votre navigateur sur http: // localhost ?

— Arjan

Le lsofgrep que vous avez utilisé reviendrait vide; les numéros de port sont mappés aux /etc/servicesnoms. Essayez lsof -i | grep http...

— Nevin Williams

En fait, le mappage / etc / services ne pose pas de problème si vous utilisez le -i :portformat, mais seulement si vous utilisez grep. Ce qui sera un problème, c'est qu'il lsoffaut des privilèges root pour voir les processus des autres utilisateurs, vous devriez donc utiliser sudo lsof -i :80(et je l'essayerais sans le grep, histoire de m'assurer ...)

— Gordon Davisson

Bonjour à tous, merci pour les suggestions jusqu’à présent, mais n’a rien révélé - même en tant que racine, et sans greps, rien n’est répertorié comme écoutant réellement le port 80.

— geoff

Avez-vous essayé lsof -i :80tout en restant connecté dans cette session Telnet? Et en plus d’essayer http: // localhost / , taper quelque chose à cette invite de Telnet révèle quelque chose ...? (Encore une fois, je sais: même si vous le comprenez de la sorte, ce ne serait pas la réponse à votre question ...)

— Arjan

Réponses:

Vous devez exécuter ces commandes rootpour afficher les processus des autres utilisateurs, par exemple:

sudo lsof -i ':80'

Mac OS X comprend un serveur Web Apache pouvant être contrôlé à l'aide apachectlde root. Il est généralement lancé via launchdle fichier de configuration correspondant /System/Library/LaunchAgents/org.apache.httpd.plist. Si ce n'est pas ce Apache en cours d' exécution sur le port 80, il est probablement Launchd , la mise en œuvre d'Apple d'un gestionnaire de démon. Selon Wikipedia :

Lorsque launchd analyse les plists de tâches au démarrage, il réserve et écoute tous les ports demandés par ces tâches. Si la clé "OnDemand" l'indique dans la liste, le démon n'est pas chargé à ce moment-là. Launchd écoutera plutôt sur le port, lancera le démon si nécessaire et l'éteindra s'il ne l'est pas. Après le chargement d’un démon, launchd en assurera le suivi et s’assurera qu’il est en cours d’exécution si nécessaire.

— Daniel Beck
source

Alors je suppose que mon idée était juste que sudo lsof -i ':80' pourrait ne pas retourner quoi que ce soit, à moins que l' un court tout en étant connecté à la session Telnet? Mais même sans ces commandes, http: // localhost / aurait probablement encore montré une page d'accueil Apache?

— Arjan

(Je pense que votre réponse est probablement la solution; elle ne correspond tout simplement pas à tous les commentaires de l'OP.)

— Arjan

Merci pour cette réponse brillante. J'ai maintenant réussi à le résoudre: 1. Il y avait une erreur dans httpd.conf, donc sudo apachectl start ne démarrait pas apache. 2. Mais launchd était à l’écoute sur le port 80, prêt à transmettre les demandes à un serveur inexistant. 3. Cependant, launchd n’écoutait pas au sens classique - c’est-à-dire - les résultats de sudo lsof -i: 80 étaient vierges, de même que pour netstat 4. Je suppose que launchd fait de la magie comme xinetd dans le sens où elle n’écoute pas officiellement un port, mais parvient à autoriser les connexions au port en corrompant le noyau.

— geoff

Pour moi, le problème était résolu sudo apachectl stopdans le terminal.

— MikeiLL

Cela n'a pas fonctionné pour moi, mais cette version ne montre ce qui était en cours d' exécution (OS High Sierra 10.13.6) sudo lsof -i -P | grep -i "80"de superuser.com/questions/984919/...

— RoboBear

Juste pour que la réponse soit claire au cas où les utilisateurs le rechercheraient.

launchd analyse le fichier /System/Library/LaunchDaemons/au démarrage et en déduit org.apache.httpd.plistque lors du démarrage d'apache, il doit lui transférer le port 80.
sudo apachectl start a été fait
Cependant, une erreur dans le httpd.conffichier signifiait qu'apache n'avait pas été démarré, bien que cela n'ait pas été signalé via la apachectlcommande.
Launchd a décidé d'écouter sur le port 80 car il pensait qu'Apache était opérationnel.
Mais le contenu de toute requête HTTP entraînait une fermeture immédiate de la connexion.
sudo lsof -i :80 pas de réponse
sudo netstat -an | grep LISTEN n'a donné aucune réponse pour le port 80
À ce que je sache, aucun outil de diagnostic n'indiquait que le port 80 était utilisé ou en cours d'écoute.
la correction du fichier httpd.conf d'apache et le redémarrage correct d'apache afin que httpd se trouve dans la table ps, a conduit les demandes HTTP à aboutir.
Je me suis donc trompé sur le fait que je ne pouvais pas exécuter Apache car il y avait déjà quelque chose à l'écoute sur le port 80, plutôt qu'apache conf était lui-même la cause

— geoff
source

Alors qu'est-ce qui n'allait pas avec httpd.conf? J'ai ce problème maintenant et je ne sais pas comment procéder en fonction de votre réponse ici .. ??

— Drew Angell

Je viens de rencontrer le même problème avec les antivirus OSX El Capitan et Avast. sudo lsof -i ':80'a montré une connexion à 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)

j'ai dû

désinstaller Avast avec /Applications/Uninstall Avast.app
sudo rm -rf "/Library/Application Support/Avast" "/Applications/Avast Business Security.app" "/Applications/Uninstall Avast.app"
redémarrer

pour l'empêcher d'utiliser le port 80.

— spyle
source