web-dev-qa-db-de.com

Supervisor scheint die Verzeichnisparameter nicht zu erfassen

Nach einem Update von Supervisor 3.0 auf 3.2 (während des Upgrades von 14.04 auf 16.04) scheint unsere Konfiguration für Supervisor nicht mehr richtig zu funktionieren.

Die Standard-Supervisor-Konfiguration ist vollständig unverändert und der einzige wichtige Parameter darin ist:

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

Im Verzeichnis conf.d befinden sich zwei Dateien. Eine, die nur auf diesem System verwendet wird und eine, die mit dem Anwendungsverzeichnis verknüpft ist, sodass wir die gleiche Konfiguration für alle Installationen verwenden können.

000-generic-environment.conf

[supervisord]
directory = /home/applicationuser/domains/<domain>/current

001-programs.conf (Symlink zu /home/applicationuser/domains//current/supervisord.conf)

[program:Push-notifications]
rabbitmq:consumer device_notifications --env=prod --no-debug -m 100
autorestart = true
user = applicationuser
command = bin/console rabbitmq:consumer device_notifications --env=prod --no-debug -m 100

Wenn ich Supervisor starte, heißt es im Protokoll nur:

supervisord[11599]: 2018-06-21 08:00:16,549 INFO spawnerr: can't find command 'bin/console'

Es versucht es einige Male und entscheidet sich dann aufgrund der erneuten Versuche, in den Zustand FATAL zu wechseln. Dieses Setup hat bei uns immer funktioniert, scheint aber jetzt kaputt zu sein. Übersehen ich hier etwas? Ich habe mir bei diesem Thema schon eine Weile den Kopf zerbrochen und könnte ein paar neue Augen in dieser Angelegenheit gebrauchen.

2
Peter van Arkel

Ich fand schließlich das Problem. Ich habe in der Dokumentation festgestellt, dass der Verzeichnisparameter nur beim Daemonisieren verwendet wird.

In Supervisor 3.0 war dies die Standardeinstellung. Anscheinend wurde nach dem Upgrade von Ubuntu und Supervisor dieses Standardverhalten geändert, und Supervisor wurde mit dem Flag -n in der Befehlszeile ausgeführt.

Das Entfernen dieses Flags in systemd hat den Daemon aus irgendeinem Grund zum Absturz gebracht, während das Ausführen von supervisord über die Befehlszeile einwandfrei funktioniert hat. Ich entschied mich für den einfachen Ausweg, weil ich mit wichtigeren Dingen weitermachen wollte, stufte den Supervisor auf 3.0 herab und alles funktionierte wieder wie ein Zauber.

1
Peter van Arkel