Supervisor lädt keine neuen Konfigurationsdateien

Ich habe ein Problem beim Bereitstellen der Django-App mit Gunicorn und Supervisor. Obwohl ich Gunicorn dazu bringen kann, meine App zu bedienen (indem ich PYTHONPATH richtig einstelle und einen entsprechenden Befehl ausführe, den aus der Supervisord-Konfiguration), kann ich Supervisor nicht dazu bringen, sie auszuführen. Meine App wird einfach nicht angezeigt. Ich weiß nicht, wie ich sicherstellen soll, dass die Konfigurationsdatei in Ordnung ist.

Hier ist was supervisorctl sagt:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

Ich starte es unter Ubuntu 10.04 mit folgender Konfiguration:

Datei /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

In /etc/supervisor/supervisord.conf befindet sich am Ende der Datei Folgendes:

[include]
files = /etc/supervisor/conf.d/*.conf

Und hier ist ein Symlink zu meiner Konfigurationsdatei:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

für mich sieht alles gut aus, aber supervisorctl sagt einfach weiter myapp_live: ERROR (no such process). Irgendeine Lösung dafür?

Ich hatte das gleiche Problem, a

sudo service supervisord reload

habe den Trick gemacht, obwohl ich nicht weiß, ob das die Antwort auf deine Frage ist.

Die richtige Antwort lautet, dass Sie vom Supervisor aufgefordert werden, die Datei erneut zu lesen und zu aktualisieren, wenn Sie eine neue Konfigurationsdatei platzieren. Ein Neustart ist nicht die Antwort, da dies Auswirkungen auf andere Dienste hat. Versuchen:

supervisorctl reread
supervisorctl update

Stellen Sie sicher, dass Ihre Supervisor-Conf-Dateien mit .conf enden

Ich habe eine Weile gebraucht, um das herauszufinden. Hoffentlich hilft es der nächsten Person.

Das erneute Laden des Master-Supervisor-Prozesses funktioniert möglicherweise, hat jedoch unbeabsichtigte Nebenwirkungen, wenn mehr als ein Prozess vom Supervisor überwacht wird.

Die richtige Vorgehensweise besteht supervisorctl rereaddarin, Folgendes auszugeben, wodurch die Konfigurationsdateien auf Änderungen überprüft werden:

root@debian:~# supervisorctl reread
gunicorn: changed

Dann lade einfach die App neu:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

Ich habe dieses Problem mit dem Supervisor-Paket, Version 3.0a8-1.1 von Ubuntu Server 12.10, festgestellt. Am Ende habe ich das Problem durch Lesen der integrierten Hilfe gelöst:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

Insbesondere möchten Sie die Syntax verwenden:

sudo supervisorctl restart myapp_live:*

Wie in der Dokumentation unter http://supervisord.org/configuration.html#programx-section angegeben - "Ein Abschnitt [program: x] repräsentiert tatsächlich eine" homogene Prozessgruppe "für den Supervisor (ab 3.0)." Vielleicht ist das Problem zuerst in Version 3.0 aufgetreten.

PS: Ich bin neu bei Supervisor; Ich verwende https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor als Beispiel dafür, wie eine minimale Konfiguration aussehen sollte.

Ich hatte ein ähnliches Problem ( myapp_live: ERROR (no such process)) und das lag an meiner Prozessdefinition

[program: myapp_live]

wann es hätte sein sollen

[program:myapp_live]

Obwohl dies nicht die gestellte Frage anspricht, wurde ich von der Suche nach einer Lösung für mein Problem hierher geführt, so dass hoffentlich auch andere Leute hier fündig werden.

Ich fand diese Lösung am bequemsten:

BEARBEITEN: Bevor Sie dies tun, überprüfen Sie Ihren Supervisor-Pfad mit which supervisorctl, um sicherzustellen, dass Sie den Sudoern den richtigen Pfad hinzufügen.

Fügen Sie diese Zeile in die sudoers-Datei ein visudo(wobei: myappuser- der Benutzer, der Ihre App neu starten muss, myapp- der Name der App):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

Und dann einfach:

sudo supervisorctl restart myapp

Sie sind nicht an die Startskripte der Distribution gebunden und Sie gewähren Benutzern, die Ihre Gunicorn-App neu starten, nur sehr eingeschränkte Berechtigungen. Außerdem müssen Sie sich nicht um pid kümmern. Der Befehl fordert nicht zur Eingabe eines Kennworts auf, sodass er für Bash- / Fabric-Skripte zur automatischen Bereitstellung geeignet ist. Andererseits müssen Sie sich bewusst sein, dass ein böswilliger Benutzer, wenn supervisorctl für einen Fehler anfällig ist, der zur Ausführung von Code führt, dieses sudo-Privileg verwenden kann, um Code als root auszuführen (aber meines Wissens wurde kein solcher Fehler für supervisord und entdeckt Es ist eine große Sache, eine solche Verwundbarkeit zu finden.

Lesen Sie den Code von supervisorctl.py hier: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Sie können sehen, dass supervisorctl update (Funktion do_update) reloadConfig () genauso aufruft wie supervisorctl reread (Funktion do_reread).

Daher denke ich, dass ein erneuter Aufruf nicht erforderlich ist, wenn Sie danach update aufrufen.

Nach der Ausgabe von git blame ist es seit mindestens Juli 2009 so.

Hier ist eine Checkliste:

1. Die neue Konfigurationsdatei sollte gemäß dem in /etc/supervisord.conf konfigurierten Include-Muster benannt werden:

   [include]
   files=supervisord.d/*.ini
   

   Wie wir in meinem Fall sehen, wäre spam.ini enthalten, spam.conf jedoch nicht.

2. Wenn Sie die neue Datei durch Kopieren einer alten erstellt haben, müssen Sie die [program:]Zeile tatsächlich ändern . Denn wenn Sie so dumm sind, als hätten Sie zwei Dateien für das gleiche Programm, supervisorctl rereadwerden Sie mit dieser hoffnungslosen Fehlermeldung bestraft:

   No config updates to processes
   

3. Wenn Ihre Datei erkannt wird, supervisorctl rereadsollten Sie Folgendes sagen:

   spam: available
   

4. Dann supervisorctl update spamsollten beide es starten und es erscheinen lassen supervisorctl status.

Ich habe festgestellt, dass die init.d-Skripte auf verschiedenen Ubuntu / Debian-Versionen unzuverlässig sind. Der Weg, dies zu tun, ist folgender:

sudo supervisorctl reload

Gehen Sie vorsichtig mit Symlinks um und fügen Sie Dateien in Supervisor ein. Es würde jeder Person mit dem Privileg /home/myapp/live/deploy/supervisord_live.ini erlauben, die INI-Datei zu ändern und bösartigen Code zu starten. Diese INI-Dateien sollten sich im Conf-Verzeichnis Ihres Supervisors oder in einem beliebigen Unterverzeichnis darunter befinden.

Ich hatte supervisrod mit yum install installiert, welches Supervisor der Version v2. * Installierte. Supervisor unterstützt nur externe Includes ab Version 3. Musste stattdessen easy_install verwenden, um Supervisor v3 zu installieren.