Le superviseur quitte toujours le processus avec «état de sortie 0; pas attendu'

13

Je suis en train de reconstruire mon vps, et j'aimerais utiliser le superviseur pour gérer mes processus django gunicorn / wsgi. Le fait est que le superviseur continue de quitter les processus:

2010-07-23 14:54:40,575 INFO supervisord started with pid 31391
2010-07-23 14:54:41,582 INFO spawned: 'projectx' with pid 31395
2010-07-23 14:54:41,691 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:42,695 INFO spawned: 'projectx' with pid 31401
2010-07-23 14:54:42,801 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:44,806 INFO spawned: 'projectx' with pid 31404
2010-07-23 14:54:44,912 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:47,917 INFO spawned: 'projectx' with pid 31408
2010-07-23 14:54:48,022 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:49,023 INFO gave up: projectx entered FATAL state, too many start retries too quickly

Voici la configuration que j'utilise:

[program:projectx]
command=/path/to/project/bin/gunicorn_django -c /path/to/project/project/gunicorn.conf.py /path/to/project/project/production.py
user=myuser
autostart=true
autorestart=true

J'ai déjà revérifié et gunicorn_django retourne le statut 0 quand il est correctement généré.

J'ai essayé d'ajouter explicitement exitcodes = 0,2 à la configuration, mais cela ne semble pas faire de différence non plus. Il semble que le processus soit correctement généré, mais le superviseur pense que ce n'est pas le cas.

Quelqu'un at-il une idée de la façon de résoudre ce problème?

Merci, Bjorn

supervisord

— Bjorn
source

12

Si gunicorn_django se démonifie, ce n'est pas le type de superviseur de programme conçu pour gérer. Le superviseur s'attend à ce que ses programmes supervisés s'exécutent au premier plan afin qu'il puisse surveiller s'ils ont quitté.

Voir les documents supervisord .

— Drew Bloechl
source

gunicorn ne se désamonise pas par défaut, mais je l'ai défini dans mon fichier de configuration. Je l'ai retiré, merci de l'avoir signalé.

— Bjorn

4

Ok, après quelques énigmes, j'ai compris que cela avait quelque chose à voir avec les utilisateurs. J'ai essayé d'exécuter mes processus enfants en tant qu'un certain utilisateur. Après avoir supprimé la ligne (voir ma config ci-dessous), tout fonctionne bien.

Config Gunicorn:

bind = "127.0.0.1:3305"
workers = 2

Configuration du superviseur:

[program:projectx]
command=/path/to/project/bin/gunicorn_django -c /path/to/project/project/gunicorn.conf.py /path/to/project/project/production.py
; set the user here instead of in the gunicorn config.
user=user
autostart=true
autorestart=unexpected
stdout_logfile=/path/to/project/logs/project.log
redirect_stderr=true
exitcodes=1

— Bjorn
source

1

Juste une note rapide que si vous voulez étoffer cela, poursuivre myuser et exécuter gunicorn devrait donner un indice. Les suspects habituels sont les fichiers journaux et pid non accessibles en écriture. Alternativement, votre application peut également avoir besoin d'autorisations de fichier. Et juste une note rapide que pour une meilleure prise en charge des superviseurs, vous devriez mettre à niveau vers 0.10 car nous avons résolu un problème avec le redémarrage de gunicorn via supervisord (ou runit d'ailleurs).

— Paul

0

J'ai eu une erreur similaire en essayant d'exécuter un démon http sous superviseur.

Corrigé en supprimant l'ancien fichier pid: httpd_pid

— Chasse au canard
source