El supervisor siempre sale del proceso con 'estado de salida 0; no esperado'

13

Actualmente estoy reconstruyendo mis vps, y me gustaría usar un supervisor para administrar mis procesos gunicorn / wsgi django. La cosa es que el supervisor sigue saliendo de los procesos:

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

Esta es la configuración que estoy usando:

[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

Ya verifiqué dos veces, y gunicorn_django devuelve el estado 0 cuando se genera correctamente.

Intenté agregar exitcodes = 0,2 explícitamente a la configuración, pero eso tampoco parece hacer la diferencia. Parece que el proceso se genera correctamente, pero el supervisor cree que no.

¿Alguien tiene idea de cómo resolver esto?

Gracias Bjorn

supervisord

— Bjorn
fuente

12

Si gunicorn_django se está demonizando a sí mismo, no es el tipo de supervisor de programa diseñado para administrar. Supervisor espera que sus programas supervisados se ejecuten en primer plano para poder monitorear si han salido.

Ver documentos del supervisor .

— Drew Bloechl
fuente

gunicorn no se desamoniza por defecto, pero lo configuré en mi archivo de configuración. Lo eliminé, gracias por señalarlo.

— Bjorn

4

Ok, después de un poco de confusión, descubrí que tenía algo que ver con los usuarios. Traté de ejecutar mis procesos secundarios como un determinado usuario. Después de eliminar la línea (ver mi configuración a continuación), todo funciona bien.

Configuración de Gunicorn:

bind = "127.0.0.1:3305"
workers = 2

Supervisor config:

[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
fuente

1

Solo una nota rápida de que si quieres desarrollar esto, demandar a mi usuario y ejecutar gunicorn debería darte una pista. Los sospechosos habituales son los archivos de registro y pid que no se pueden escribir. Alternativamente, su aplicación también podría necesitar permisos de archivo. Y solo una nota rápida de que para un mejor soporte del supervisor, debe actualizar a 0.10 ya que solucionamos un problema al reiniciar gunicorn a través del supervisor (o runit para el caso).

— Paul J. Davis

0

Recibí un error similar al intentar ejecutar un demonio http bajo supervisión.

Solucionado al eliminar el viejo archivo pid: httpd_pid

— caza de patos
fuente