Nginx ne s'arrête pas et nginx.pid est manquant
Je veux arrêter Nginx mais ça échoue comme ça.
$ Sudo service nginx stop
Stopping nginx: [FAILED]
Et nginx.conf Qui définit l'emplacement de nginx.pid ont une ligne.
# /etc/nginx/nginx.conf
pid /var/run/nginx.pid;
Mais il n'y a pas de nginx.pid Dans le répertoire /var/run/.
locate nginx.pid Affiche cette sortie.
/var/run/nginx.pid
/var/run/nginx.pid.oldbin
Mais après updatedb il n'y a pas de correspondance pour la recherche. J'utilise nginx/1.4.4 dans CentOS release 6.5 (Final).
Que dois-je faire pour arrêter le démon nginx?
Modifier 2014/01/07
C'est la sortie de ps -ef | grep nginx, Il semble que le démon nginx soit toujours en cours d'exécution.
ironsand 17065 16933 0 15:55 pts/0 00:00:00 grep --color nginx
root 19506 1 0 2013 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
ironsand 19507 19506 0 2013 ? 00:00:25 nginx: worker process
Et Sudo service nginx restart Donne cette erreur. Je pense que nginx ne démarre pas parce que l'ancien est toujours vivant. Et /var/log/nginx/error.log-2014017 Contient également cette erreur.
Stopping nginx: [FAILED]
Starting nginx: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[FAILED]
Je recommanderai d'arrêter nginx en tuant d'abord son processus maître. Le nginx n'est pas arrêté correctement peut être à cause de cela, il ne peut pas être arrêté à l'aide du script init.
ps -ef | grep nginx
Cela vous montrera le PID du processus maître nginx. Comme vous l'avez mentionné ci-dessus:
racine 19506 1 0 2013? 00:00:00 nginx: processus maître/usr/sbin/nginx -c /etc/nginx/nginx.conf
Tuez-le en utilisant
tuer -9 19506
Vérifiez à nouveau si un processus nginx est en cours d'exécution ou si le port 80 est occupé. Si vous voyez qu'un processus est lié au port 80, identifiez le PID et vérifiez s'il peut être tué.
ps -ef | grep nginx
netstat -tulpn | grep 80
assurez-vous que le système de fichiers fonctionne correctement et que vous pouvez lire/écrire dans le système de fichiers/var. Ensuite, démarrez nginx
service nginx start
Problème
Pour moi, le nom du fichier pid était différent dans ces deux fichiers:
- /usr/lib/systemd/system/nginx.service
pid /var/run/nginx.pid;
- /etc/nginx/nginx.conf
PIDFile=/run/nginx.pid
Ces deux doivent correspondre.
Réparer:
Je l'ai donc ajusté dans /usr/lib/systemd/system/nginx.service, puis j'ai fait:
systemctl daemon-reload
systemctl start nginx
Ensuite, il est venu correctement.
J'ai eu ce problème et j'ai exécuté ps -ef | grep nginx me montrerait des travailleurs qui continueraient de tourner, malgré la mort du processus maître comme le suggère la réponse acceptée:
[~]# ps -ef | grep nginx
nginx 10730 1 0 Sep14 ? 00:00:16 nginx: cache manager process
nginx 18469 1 0 Oct09 ? 00:11:02 nginx: worker process
nginx 25779 1 0 Oct13 ? 00:01:31 nginx: worker process
nginx 26458 1 0 15:45 ? 00:00:00 nginx: worker process
Alors ma solution pour le réparer c'était simplement ceci: pkill nginx && service nginx restart
Mon problème était que j'avais pid spécifié dans deux fichiers de conf différents. Après avoir supprimé une référence, j'ai supprimé le .pid fichier et a redémarré nginx, il a commencé à se comporter normalement.
J'ai eu un problème similaire avec Ubuntu 10.10 et une version compilée de nginx exécutée dans/opt/nginx/sbin.
vérifiez les deux fichiers /opt/nginx/conf/nginx.conf et /etc/nginx/nginx.conf et vérifiez qu'ils correspondent.
Ajustez le fichier de démarrage /etc/init.d/nginx pour qu'il corresponde au test d'emplacement nginx.pid en utilisant:
Sudo /etc/init.d/nginx configtest # should show no failures
Sudo /etc/init.d/nginx start # should show starting
Sudo /etc/init.d/nginx status # should show running
Sudo /etc/init.d/nginx stop # should show stopping -- (wait for a few)
Sudo /etc/init.d/nginx status # should show can not access PID file for nginx
Sudo netstat -tap # should not show nginx program running with open local address
Cela semble indiquer que nginx plante immédiatement, s'il avait été démarré plus tôt. Avez-vous vérifié le contenu de /var/log/nginx* pour voir ce que fait le processus?
EDIT: De plus, si vous nous dites votre système d'exploitation et votre version de nginx, nous pouvons donner des réponses plus détaillées.
Pour arrêter nginx, consultez le manuel comment le faire man nginx.
La manière par défaut devrait être d'utiliser le signal d'arrêt avec nginx -s stop.
Ça devrait être aussi simple que ça. Vos options sont:
stop, quit, reopen, reload.
Essaye ça:
Sudo fuser -k 443/tcp
Sudo fuser -k 80/tcp
Je l'ai trouvé ici: https://www.digitalocean.com/community/questions/nginx-is-unable-to-bind-to-44
J'aurais besoin de plus d'informations pour être sûr, mais je suppose que vous avez déjà n autre serveur Web en cours d'exécution plutôt que l'instance de ngnix que vous voulez vous-même, vous devez donc la trouver - l'erreur indique le port 80 est utilisé, mais pas par quoi
Essayez netstat -tulpn - Vous recherchez une entrée sous une adresse locale qui se termine par: 80 - cela vous donnera également le nom du programme et le PID afin que vous puissiez l'identifier. Voici le mien - je lance lighttpd et son affiché sur la 3ème ligne.
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5000 0.0.0.0:* LISTEN 4684/rtorrent
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 923/php-fpm.conf)
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 972/lighttpd
tcp 0 0 0.0.0.0:6901 0.0.0.0:* LISTEN 4684/rtorrent
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 720/sshd
tcp6 0 0 :::22 :::* LISTEN 720/sshd
udp 0 0 0.0.0.0:6881 0.0.0.0:* 4684/rtorrent
Arrêtez l'autre serveur Web correctement (car si son apparition par le haut, un 'kill' normal peut ne pas fonctionner) et essayez de démarrer ngnix. Si tel est le cas, vous pouvez/devez alors modifier vos scripts d'initialisation pour arrêter l'autre serveur Web de démarrer, ou ajuster sa configuration sur une autre alimentation.