Le superviseur ne charge pas les nouveaux fichiers de configuration

J'ai rencontré ce problème en utilisant le paquet supervisor, version 3.0a8-1.1 d'Ubuntu Server 12.10. J'ai fini par résoudre le problème en lisant l'aide intégrée :

$ 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

En particulier, vous voulez utiliser la syntaxe :

sudo supervisorctl restart myapp_live:*

Comme l'indique la documentation à l'adresse http://supervisord.org/configuration.html#programx-section -- "Une section [programme:x] représente en fait un "groupe de processus homogène" pour le superviseur (à partir de la version 3.0)." Donc peut-être que le problème a fait surface pour la première fois dans la version 3.0.

PS : Je suis nouveau dans le domaine du superviseur ; j'utilise https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor comme un exemple de ce à quoi devrait ressembler une configuration minimale.

Voici une liste de contrôle :

1. Le nouveau fichier de configuration doit être nommé selon le modèle d'inclusion configuré dans /etc/supervisord.conf :

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

   Comme nous le voyons dans mon cas, spam.ini serait inclus, mais spam.conf ne le serait pas.

2. Si vous avez créé le nouveau fichier en copiant un ancien fichier, assurez-vous de modifier réellement l'adresse de l'utilisateur. [program:] ligne. Parce que si vous êtes aussi stupide que d'avoir deux fichiers pour le même programme, supervisorctl reread vous laissera avec ce message d'erreur désespéré comme punition :

   No config updates to processes

3. Si votre fichier est détecté, supervisorctl reread devrait dire quelque chose comme :

   spam: available

4. Ensuite, supervisorctl update spam devrait à la fois le démarrer et le faire apparaître dans supervisorctl status .

J'ai trouvé que les scripts de init.d n'étaient pas fiables sur une variété de différentes versions Ubuntu/Debian. La façon de procéder est la suivante :

sudo supervisorctl reload

J'ai trouvé cette solution très pratique :

EDIT : avant de faire cela, vérifiez votre chemin supervisorctl en utilisant which supervisorctl pour s'assurer que vous ajoutez le bon chemin à sudoers.

Ajoutez cette ligne au fichier sudoers en utilisant visudo (où : myappuser - l'utilisateur qui doit redémarrer votre application, myapp - nom de l'application) :

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

Et puis tout simplement :

sudo supervisorctl restart myapp

Vous n'êtes pas lié aux scripts de démarrage de la distribution et vous donnez des privilèges assez étroits à l'utilisateur qui redémarre votre application gunicorn. De plus, vous n'avez pas besoin de vous soucier du pid. La commande ne demandera pas de mot de passe donc elle est adaptée au déploiement automatique bash/fabric scripts. D'un autre côté - vous devez être conscient, que si supervisorctl est vulnérable à un bug causant l'exécution de code, un utilisateur malveillant pourrait utiliser ce privilège sudo pour exécuter du code en tant que root (mais pour autant que je sache, aucun bug de ce type n'a été découvert pour supervisord et c'est une grande chose de trouver une telle vulnérabilité).

Je lis le code de supervisorctl.py ici : https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Vous pouvez voir que supervisorctl update (fonction do_update) appelle reloadConfig() exactement comme le fait supervisorctl reread (fonction do_reread).

Je pense donc que l'appel à reread n'est pas nécessaire si vous appelez update après.

D'après la sortie de git blame, il en est ainsi depuis au moins juillet 2009.