Le superviseur ne semble pas prendre le paramètre de répertoire
Après une mise à jour de superviseur 3.0 à 3.2 (lors de la mise à niveau de 14.04 à 16.04), notre configuration que nous utilisons pour superviseur ne semble plus fonctionner correctement.
La configuration du superviseur par défaut est complètement inchangée et le seul paramètre important dans ce fichier est:
[include]
files = /etc/supervisor/conf.d/*.conf
Dans le répertoire conf.d, il y a deux fichiers; l'un qui est utilisé uniquement sur ce système et l'autre qui crée des liens symboliques dans le répertoire de l'application, afin que nous puissions utiliser la même configuration sur toutes les installations.
000-generic-environment.conf
[supervisord]
directory = /home/applicationuser/domains/<domain>/current
001-programs.conf (lien symbolique vers /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
Lorsque je commence superviseur, la seule chose que dit le journal est la suivante:
supervisord[11599]: 2018-06-21 08:00:16,549 INFO spawnerr: can't find command 'bin/console'
Il essaie plusieurs fois puis décide de passer à l'état FATAL à cause des tentatives. Cette configuration a toujours fonctionné pour nous, mais semble maintenant être en panne. Est-ce que je néglige quelque chose ici? Cela fait un moment que je me casse la tête sur cette question et je pourrais avoir un regard neuf sur la question.
J'ai finalement trouvé le problème. J'ai remarqué dans la documentation que le paramètre directory n'était utilisé que lors du démonisation.
Dans Supervisor 3.0, il s'agissait de la valeur par défaut. apparemment après la mise à niveau d'ubuntu et de superviseur, ce comportement par défaut a été modifié et superviseur s'est exécuté avec l'indicateur -n sur la ligne de commande.
La suppression de cet indicateur dans systemd a bloqué le démon pour une raison quelconque, alors que l’exécution de supervisord à partir de la ligne de commande fonctionnait parfaitement. En choisissant la solution de facilité, parce que je voulais continuer avec des tâches plus importantes, j'ai rétrogradé superviseur à 3.0 et tout a fonctionné à merveille.