Supervisor beendet den Prozess immer mit 'exit status 0; unerwartet'

13

Ich baue gerade mein vps um und möchte Supervisor für die Verwaltung meiner Gunicorn- / Wsgi-Django-Prozesse verwenden. Der Supervisor verlässt ständig die Prozesse:

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

Dies ist die Konfiguration, die ich benutze:

[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

Ich habe es bereits doppelt überprüft und gunicorn_django gibt den Status 0 zurück, wenn es korrekt erzeugt wurde.

Ich habe versucht, exitcodes = 0,2 explizit zur Konfiguration hinzuzufügen, aber das scheint auch keinen Unterschied zu machen. Es sieht so aus, als ob der Prozess korrekt erzeugt wurde, aber der Supervisor glaubt, dass dies nicht der Fall ist.

Hat jemand eine Ahnung, wie man das löst?

Danke, Björn

supervisord

— Björn
quelle

12

Wenn sich gunicorn_django selbst dämonisiert, ist dies nicht die Art von Programm-Supervisor, die für die Verwaltung vorgesehen ist. Supervisor erwartet, dass seine überwachten Programme im Vordergrund ausgeführt werden, damit überwacht werden kann, ob sie beendet wurden.

Siehe supervisord docs .

— Drew Bloechl
quelle

gunicorn deamonisiert sich nicht automatisch, aber ich habe es in meiner Konfigurationsdatei festgelegt. Ich habe es entfernt, danke, dass Sie darauf hingewiesen haben.

— Bjorn

4

Ok, nach ein paar Rätseln habe ich herausgefunden, dass es etwas mit Benutzern zu tun hat. Ich habe versucht, meine untergeordneten Prozesse als bestimmter Benutzer auszuführen. Nachdem Sie die Zeile entfernt haben (siehe meine Konfiguration unten), funktioniert alles einwandfrei.

Gunicorn-Konfiguration:

bind = "127.0.0.1:3305"
workers = 2

Supervisor-Konfiguration:

[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

— Björn
quelle

1

Nur eine kurze Anmerkung, wenn Sie dies ausarbeiten möchten, sollte myuser und running gunicorn einen Hinweis geben. Die üblichen Verdächtigen sind die Protokoll- und PID-Dateien, die nicht beschreibbar sind. Alternativ benötigt Ihre App möglicherweise auch Dateiberechtigungen. Um die Supervisor-Unterstützung zu verbessern, sollten Sie ein Upgrade auf 0.10 durchführen, da wir ein Problem beim Neustart von Gunicorn über Supervisord (oder Runit) behoben haben.

— Paul J. Davis

0

Beim Versuch, einen http-Daemon unter Supervisor auszuführen, ist ein ähnlicher Fehler aufgetreten.

Behoben durch Entfernen der alten PID-Datei: httpd_pid

— Entenjagd
quelle