Nginx en "double"...?

Support
1

Hello,

J’ai un petit souci depuis une install d’app foireuse (qui m’a tout supprimé dans /var/www - j’ai pu à peu près sauver l’install depuis) mon nginx tourne, désolé pour les termes vagues, « indépendamment de systemd ».

Je m’explique. nginx est bien fonctionnel (et d’ailleurs tout mon yunohost fonctionne nickel) cependant il est vu comme en échec par systemd:

# systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Thu 2017-11-16 19:25:46 CET; 1s ago
  Process: 11912 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)
  Process: 11909 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)

Il y a en effet une autre instance de nginx en exécution :

# ps faux | grep nginx
root      1090  0.0  0.2 118676  2184 ?        Ss   Nov08   0:00 nginx: master process /usr/sbin/nginx
www-data  1091  0.0  1.2 120788 11512 ?        S    Nov08   1:59  \_ nginx: worker process
www-data  1092  0.0  1.2 120796 11468 ?        S    Nov08   1:54  \_ nginx: worker process
www-data  1093  0.0  1.2 120644 11432 ?        S    Nov08   2:01  \_ nginx: worker process
www-data  1094  0.0  1.1 120652 11340 ?        S    Nov08   1:59  \_ nginx: worker process

Et du coup, forcément :

# systemctl start nginx
Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.

# journalctl -xn
...
2017/11/16 19:27:23 [emerg] 12044#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2017/11/16 19:27:23 [emerg] 12044#0: bind() to [::]:80 failed (98: Address already in use)
2017/11/16 19:27:23 [emerg] 12044#0: bind() to 0.0.0.0:443 failed (98: Address already in use)
2017/11/16 19:27:23 [emerg] 12044#0: bind() to [::]:443 failed (98: Address already in use) 
...

Et du coup y’a un certain nombre de fonctionnalités d’admin (domaines, apps…) qui foirent juste à cause de ça (le restart/reload de nginx à la fin les fait foirer).

Je peux killer tout le monde et faire un restart du service, et tout revient dans l’ordre… Jusqu’au reboot.

C’est là que j’ai besoin d’aide. J’ai aucune idée de comment ce nginx fantôme est lancé. En plus, je suis une brelle en systemd, et en init en général, du coup je ne sais même pas où regarder. Si vous avez une astuce, je prends volontiers !

2

Salut,

c’est a peu près normal qu’il y’ai “plusieurs” nginx qui tournent : nginx lance des “workers” (‘ouvriers’) pour pouvoir traiter facilement plusieurs requetes en parralèles.

Par contre, quand tu restart nginx, il devrait pas te dire que quelqu’un utilise deja le port 80…

Est-ce que tu es sur que ca fait aussi le probleme si tu fais systemctl restart nginx (au lieu de start)

Si oui, alors tu peux investiger les processus qui utilisent des ports avec netstat -l | grep 443 par exemple

3

c’est a peu près normal qu’il y’ai “plusieurs” nginx qui tournent : nginx lance des “workers” (‘ouvriers’) pour pouvoir traiter facilement plusieurs requetes en parralèles.

Pardon, je me suis mal exprimé. Je sais qu’il est normal d’avoir des workers (d’ailleurs c’est marqué dans la sortie de ps : “master” vs “worker”).

Par contre, si tu compares la sortie de ps et celle de systemctl status nginx tu peux voir que les PID sont différents. Tout semble indiquer que nginx s’est lancé par un canal X (en spawnant ses workers aussi), puis que systemd a à son tour tenté de démarrer le service, en échouant puisqu’il y a déjà quelqu’un qui écoute sur les ports. Ou que d’une manière X ou Y, le master nginx avec le PID 1090 s’est “détaché” de systemd.

Ca fait bien pareil si je fais restart (ou stop et start). systemd ne contrôle pas les process qui sont listés par ps.

Et les process qui écoutent sur 80/443 sont bien ces nginx.

4

Oh oké

Ben heu du coup ca donne l’impression que ce nginx a été lancé indépendamment de systemd, et qu’il faudrait le kill pour pouvoir laisser systemd le gérer ?

5

C’est ce que j’ai fait. Mais il se relance au reboot, et je ne trouve pas par quel moyen :frowning: