Après avoir installé httpd24 avec brew vous avez deux environnements de serveur web Apache complètement différents :
- httpd24 de brew
- le httpd original de macOS/OS X
Les deux ont des fichiers de configuration et des binaires apachectl (et autres) différents. Le premier est installé dans /usr/local/Cellar/httpd24 et ses binaires sont liés à /usr/local/bin. Les binaires liés à httpd de macOS sont situés dans /usr/sbin.
En fonction de votre variable PATH (entrez echo $PATH
pour l'obtenir) sudo apachectl [cmd]
contrôle soit le premier, soit le second environnement Apache.
Après l'installation de brew, le PATH par défaut devrait être /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
qui favorise le httpd24 de Brew. Vous pouvez cependant contrôler Apache de macOS en utilisant le chemin complet (/usr/sbin/apachectl).
Si vous avez un chemin différent qui ne favorise pas /usr/local/bin par rapport à /usr/sbin, c'est l'inverse. Pour obtenir le chemin de l'option privilégiée apachectl vous pouvez aussi simplement entrer which apachectl
.
Vérifiez cela avec /usr/local/bin/apachectl -S
ce qui devrait donner :
VirtualHost configuration:
ServerRoot: "/usr/local/opt/httpd24"
Main DocumentRoot: "/usr/local/var/www/htdocs"
Main ErrorLog: "/usr/local/var/log/apache2/error_log"
Mutex default: dir="/usr/local/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
PidFile: "/usr/local/var/run/apache2/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="daemon" id=1 not_used
Group: name="daemon" id=1 not_used
y /usr/sbin/apachectl -S
VirtualHost configuration:
ServerRoot: "/usr"
Main DocumentRoot: "/Library/WebServer/Documents"
Main ErrorLog: "/private/var/log/apache2/error_log"
Mutex default: dir="/private/var/run/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex proxy: using_defaults
PidFile: "/private/var/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="_www" id=70 not_used
Group: name="_www" id=70 not_used
Hay pas de les fichiers/dossiers utilisés mutuellement.
Ils utilisent également des fichiers de configuration standard différents :
/usr/local/bin/apachectl -t -D DUMP_INCLUDES
Included configuration files:
(*) /usr/local/etc/apache2/2.4/httpd.conf
La commande ne fonctionne pas correctement pour l'apachectl original (macOS) cependant et ne donne que des résultats : Syntaxe OK.
Si vous exécutez les deux httpds (en configurant des ports différents ici : 80 : macOS ; 8080 httpd24 - vérifiez cela dans les fichiers de configuration respectifs) ps -aef | grep httpd | grep -v grep
affichera ce qui suit :
0 76 1 0 4:54pm ?? 0:00.13 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 219 76 0 4:54pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 220 76 0 4:54pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 221 76 0 4:54pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 222 76 0 4:54pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 223 76 0 4:54pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
1 4239 76 0 5:06pm ?? 0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
0 8251 1 0 5:45pm ?? 0:00.08 /usr/sbin/httpd -D FOREGROUND
70 8261 8251 0 5:46pm ?? 0:00.00 /usr/sbin/httpd -D FOREGROUND
Les sept premiers pids appartiennent à httpd24, les deux derniers à httpd de macOS - vérifiez les chemins binaires indiqués ! et nmap localhost
:
Starting Nmap 7.31 ( https://nmap.org ) at 2016-12-22 18:00 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00039s latency).
Other addresses for localhost (not scanned): ::1 fe80::1
Not shown: 499 closed ports, 498 filtered ports
PORT STATE SERVICE
80/tcp open http
8080/tcp open http-proxy
Dans votre message de chat privé vous pouvez clairement voir que httpd24 n'est pas ne fonctionne pas du tout, mais le httpd de macOS est .
Pour désactiver le httpd de macOS, exécutez simplement sudo /usr/sbin/apachectl stop
et en outre sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
(juste pour être sûr).
Ensuite, jetez le brew service start ...
en arrêtant le service et en installant un vrai démon plist comme recommandé dans le guide pratique lié.
sudo cp -v /usr/local/Cellar/httpd24/2.4.23_2/homebrew.mxcl.httpd24.plist /Library/LaunchDaemons
sudo chown -v root:wheel /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo chmod -v 644 /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
Redémarrez. Si vous obtenez toujours une erreur en vous connectant avec localhost:8080 à votre site de développement local, commentez les points suivants fe80::1%lo0 localhost
dans /etc/hosts. Dans mon environnement, cela fonctionne avec cette ligne cependant.
Après des recherches plus approfondies, il s'avère qu'un proxy web mal configuré (faisant partie de l'Internet Security/Antivirus d'ESET) est le coupable. En ajoutant un localhost
exclure il devrait être possible de résoudre le problème.
1 votes
Est-ce que "ping localhost" donne 127.0.0.1 ? Vous pouvez également vérifier /etc/hosts.
0 votes
Oui, ping localhost se résout à 127.0.0.1 127.0.0.1 localhost 255.255.255.255 broadcasthost
0 votes
Avez-vous d'anciens fichiers de configuration qui définissent un hôte virtuel ? Ou y a-t-il quelque chose dans les fichiers journaux d'Apache ? Voyez-vous quelque chose se produire lorsque vous éjectez tous les fichiers journaux et essayez d'accéder à localhost ? "tail -f /usr/local/var/log/apache2/*"
0 votes
Je ne suis pas sûr, je ne connais pas vraiment les configurations du serveur, je bricole jusqu'à ce que les choses fonctionnent. Voici un lien vers le résultat lorsque je lance l'appel de queue : fichier Gist
0 votes
Il semble qu'il y ait encore un autre processus en cours d'exécution qui utilise les ports. Donc je suppose que vous devez l'arrêter d'abord.
0 votes
J'ai fait un ps aux | grep localhost:8080 <code><pre> ps aux | grep localhost:8080 tony 66074 0.0 0.0 2444056 700 s003 U+ 12:52PM 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude -dir=.git --exclude-dir=.hg --exclude-dir=.svn localhost:8080 </pre></code>
0 votes
Cherchez le processus avec : "ps -aef | grep httpd | grep -v grep". Puisque le processus d'apache est appelé httpd et non localhost
0 votes
Vous pouvez tuer l'apache en cours d'exécution avec la commande suivante : ps -aef | grep " httpd " | grep -v grep |kill $(awk '{print $2}')
0 votes
Ce site est le lien vers la sortie Désolé pour le formatage, donc je devrais juste exécuter
kill
sur tous les processus httpd ?0 votes
Oui, comme il y a un autre processus apache en cours, vous ne pouvez pas démarrer votre version mise à jour. Vous devez les arrêter ou, si cela ne fonctionne pas, les tuer, avant de pouvoir démarrer votre nouveau serveur avec apachectl start.
0 votes
Ok, ça a du sens. Je vais essayer. Merci pour votre aide, je l'apprécie !
0 votes
Pas d'inquiétude, la commande : * ps -aef | grep " httpd " | grep -v grep |kill $(awk '{print $2}') * devrait fonctionner et faire le travail pour vous. Après cela, vous pouvez démarrer le nouvel apache avec * sudo apachectl -k restart *
0 votes
L'exécution de cette commande semble prendre beaucoup de temps, mais rien ne se passe encore.
0 votes
J'ai installé la plupart des éléments d'Apache et de PHP avec
homebrew
si cela peut vous aider ?0 votes
Si cela prend beaucoup de temps, c'est qu'il essaie probablement de redémarrer tous les processus apache tués. Pouvez-vous simplement essayer de l'arrêter avec : * sudo apachectl stop * et vérifier les processus en cours après ?
0 votes
Vamos a continuer cette discussion dans le chat .
0 votes
`httpd (pid 39269 ?) ne fonctionne pas1
0 votes
Si c'est l'apache intégré d'OS X qui fonctionne, vous pouvez le désactiver avec
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
. Si le message "Impossible de trouver le service spécifié" s'affiche, cela signifie que le service n'est pas activé et que vous devez chercher la source du problème ailleurs.0 votes
@GordonDavisson qui a tué le httpd fourni avec Apple mais n'a pas résolu le localhost:8080, je dois toujours y accéder via : 127.0.0.1:8080 C'est étrange.
0 votes
@pixel67 C'est peut-être une question d'IPv6. localhost se résout en 127.0.0.1 (IPv4). et ::1 (IPv6) et fe80::1%lo0 (également IPv6), donc si vous avez apache qui n'écoute que sur IPv4, localhost peut ne pas l'atteindre.
0 votes
127.0.0.1 localhost255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost
0 votes
C'est le fichier /ets/hosts
2 votes
Localhost peut également être résolu vers une adresse IPv6 alors que 127.0.0.1 est garanti comme étant ipv4. Votre application peut se comporter différemment selon qu'il s'agit d'une adresse IPv6 ou d'une adresse ipv4.