Il supervisore ha sempre chiuso il processo con 'exit status 0; inatteso'

13

Attualmente sto ricostruendo i miei vps e mi piacerebbe usare il supervisore per gestire i miei processi gunicorn / wsgi django. Il fatto è che il supervisore continua a uscire dai processi:

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

Questa è la configurazione che sto 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

Ho già ricontrollato e gunicorn_django restituisce lo stato 0 quando viene generato correttamente.

Ho provato ad aggiungere esplicitamente exitcodes = 0,2 alla configurazione, ma neanche quello sembra fare la differenza. Sembra che il processo sia stato generato correttamente, ma il supervisore pensa di no.

Qualcuno ha idea di come risolverlo?

Grazie Bjorn

supervisord

— Bjorn
fonte

12

Se gunicorn_django si sta demonizzando da solo, non è il tipo di supervisore del programma progettato per essere gestito. Il supervisore si aspetta che i suoi programmi supervisionati vengano eseguiti in primo piano in modo da poter monitorare se sono usciti.

Vedi i documenti di supervisord .

— Drew Bloechl
fonte

gunicorn non si deamonizza di default, ma l'ho impostato nel mio file di configurazione. L'ho rimosso, grazie per averlo sottolineato.

— Bjorn,

4

Ok, dopo qualche enigma ho capito che aveva qualcosa a che fare con gli utenti. Ho provato a eseguire i processi figlio come un determinato utente. Dopo aver rimosso la linea (vedi la mia configurazione di seguito), tutto funziona bene.

Configurazione Gunicorn:

bind = "127.0.0.1:3305"
workers = 2

Configurazione supervisore:

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

1

Solo una breve nota che se si desidera dare una svolta a questo, fare causa a mio utente e eseguire il gunicorn dovrebbe dare un suggerimento. I soliti sospetti sono i file log e pid che non sono scrivibili. In alternativa, anche l'app potrebbe richiedere autorizzazioni per i file. E solo una breve nota che per un migliore supporto dei supervisori dovresti aggiornare a 0.10 poiché abbiamo risolto un problema con il riavvio di gunicorn tramite supervisord (o runit per quella materia).

— Paul J. Davis,

0

Ho riscontrato un errore simile durante il tentativo di eseguire un demone http sotto supervisore.

Risolto rimuovendo il vecchio file pid: httpd_pid

— duckhunt
fonte