Supervisor lädt keine neuen Konfigurationsdateien

68

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?

Grucha
quelle
Ich kratzte mir mit demselben Problem am Kopf. Meine Konfigurationsdateien wurden beim Ausführen von rereadoder nicht geladen update. Es stellte sich heraus, dass ich meine Konfigurationsdateien gespeichert hatte, foo.conf.pyanstatt foo.confdass sie nicht identifiziert wurden.
Timmy O'Mahony

Antworten:

31

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.

Hixi
quelle
2
Ich habe vor einiger Zeit angehalten und dann den Supervisor gestartet, und es hat funktioniert. Ich weiß nicht, ob das Neuladen funktionieren würde (da ich es nicht von Herzen neu
starte
Ich habe es auch getan und es hat funktioniert. Ich frage mich, warum /etc/init.d/supervisor restartes nicht funktioniert, wenn manuelles Stoppen und Starten funktioniert.
Kirill
1
Arbeitete für mich, obwohl der Service nicht funktionierte, so lief ich nur ps aux | grep supervisorund dannsudo kill -HUP pid
Wayne Werner
2
Dies ist gefährlich, da der gesamte Supervisor-Daemon neu gestartet wird.
Mark Theunissen
7
supervisorctl reread kann dies auch beheben, ohne den Dienst neu zu starten.
Jonathan Liuti
199

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
Mark Theunissen
quelle
13
Dies sollte die richtige Antwort sein. "Supervisor Reread" allein reicht nicht aus.
Miebster
3
+1 Dies ist eine bessere Antwort, da sie nicht auf Prozessmanagern basiert.
Gezeitenwall
8
"supervisorctl reread" allein reicht nicht aus, aber würde "supervisorctl update" nicht ausreichen? Laut Dokumentation führt "update" ein erneutes Lesen durch, gefolgt von einem Neustart aller Programme, deren Konfiguration durch das erneute Lesen geändert wurde.
BlueBomber
Es funktioniert bei mir. Ich habe danach einen Neustart durchgeführt.
user1012513
15

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.

Nym
quelle
1
Vergeudete eine Stunde für das gleiche Thema - kann nicht glauben, dass es so einfach war.
Zane Hooper
1
Vielen Dank für die Auflistung dieser Antwort. Für mein Leben konnte ich das nicht herausfinden.
Phillip Martin
14

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
Burhan Khalid
quelle
Dies ist die beste Lösung, wenn Sie nur eine geänderte / neue Konfigurationsdatei lesen und den Rest der laufenden Prozesse unberührt lassen möchten. Supervisorctl zeigt die neue App ist avail. Fügen Sie es zu den (neu) startbaren Prozessen hinzu, indem Sie es ausgeben supervisorctl update. Siehe auch Marks Antwort serverfault.com/a/479754/125887
Sjaak Trekhaak
4
Das hat mir nicht gereicht. supervisorctl updateWar notwendig.
Jaroslaw Nikitenko
5

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.

Picomancer
quelle
4

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.

Conrad.Dean
quelle
Hier gilt das gleiche! Ich hatte es so belassen, als ob ich [program]den Dokumenten gefolgt wäre, aber als ich es [program:redis]gemacht hatte, funktionierte es für mich. Manchmal werden die Dinge wirklich komisch!
Ankush981
2

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.

pielgrzym
quelle
2

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.

Sebastien Estienne
quelle
2

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.

user2394284
quelle
1

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
mafrosis
quelle
Dies ist nicht der richtige Weg, obwohl es unter vielen Umständen funktionieren wird. @ burhan-khalid Antwort ist die richtige und bietet eine Erklärung dafür.
Glarrain
1

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.

Leo Pepe
quelle
0

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.

Aidas
quelle
Dies war auch mein Problem, es wird wahrscheinlich bei allen Centos 6.5 oder weniger-Installationen auftreten.
Bearrito