Superviseur ne charge pas de nouveaux files de configuration

J'ai un problème déployant l'application Django à l'aide de Gunicorn et Supervisor. Bien que je puisse faire en sorte que Gunicorn serve mes applications (en définissant correctement PYTHONPATH et en exécutant une command appropriée, celle de config de controller), je ne peux pas faire fonctionner le superviseur pour l'exécuter. Il ne verra plus mon application. Je ne sais pas comment m'assurer si le file de configuration est correct.

Voici ce que le superviseur dit:

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

Je l'exécute sur Ubuntu 10.04 avec la configuration suivante:

Fichier /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 

Dans /etc/supervisor/supervisord.conf, à la fin du file, il y a:

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

et voici un lien symbolique dans mon file de configuration:

 # 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 

tout semble bien pour moi, mais superviseur, continuez à dire myapp_live: ERROR (no such process) . Une solution pour cela?

J'ai eu le même problème, un

 sudo service supervisord reload 

a fait l'affaire, mais je ne sais pas si c'est la réponse à votre question.

La réponse correcte est que le superviseur exige que vous ré-lisez et mettez à jour lorsque vous placez un nouveau file de configuration. Le redémarrage n'est pas la réponse, car cela affectera d'autres services. Essayer:

 supervisorctl reread supervisorctl update 

Le rechargement du process du maître superviseur peut fonctionner, mais il aura des effets secondaires involontaires si vous avez surveillé plus d'un process par le superviseur.

La façon correcte de le faire est de publier une supervisorctl reread qui l'oblige à parsingr les files de configuration pour toutes les modifications:

 root@debian:~# supervisorctl reread gunicorn: changed 

Ensuite, il suffit de recharger cette application:

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

Assurez-vous que vos files conf du controller se terminent par .conf

Je me suis pris un moment pour comprendre ça. J'espère qu'il aide la prochaine personne.

J'ai eu un problème similaire ( myapp_live: ERROR (no such process) ) et c'est parce que ma définition de process était

 [program: myapp_live] 

quand cela aurait dû être

 [program:myapp_live] 

Bien que cela ne traite pas de la question qui a été posée, j'ai été mener ici par la Recherche qui search une solution à mon problème, alors j'espère que d'autres personnes le trouvent également ici.

J'ai rencontré ce problème en utilisant le packageage superviseur, version 3.0a8-1.1 à partir du server Ubuntu 12.10. J'ai fini par résoudre le problème en lisant l'aide embeddede:

 $ 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 souhaitez utiliser la syntaxe:

 sudo supervisorctl restart myapp_live:* 

Comme la documentation l'indique à http://supervisord.org/configuration.html#programx-section – "Une section [programme: x] représente réellement un" groupe de process homogène "pour le superviseur (à partir de 3.0)." Donc, peut-être, le problème a été abordé dans la version 3.0.

PS: Je suis nouveau au superviseur; J'utilise https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor comme exemple de la configuration minimale.

J'ai trouvé cette solution la plus pratique:

EDIT: avant de faire ceci, vérifiez votre path de superviseur en utilisant which supervisorctl pour vous assurer d'append le bon path aux sudoers.

Ajoutez cette ligne au file sudoers à l'aide de visudo (où: myappuser – l'user qui doit redémarrer votre application, myapp – nom de l'application):

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

Et puis, simplement:

 sudo supervisorctl restart myapp 

Vous n'êtes pas lié aux scripts de démarrage de la dissortingbution et vous confiez des privilèges assez étroits à l'user redémarrant votre application Gunicorn. Aussi, vous n'avez pas besoin de vous préoccuper de pid. La command ne requestra pas de mot de passe, donc elle convient aux scripts bash / fabric de deployment automatique. D'autre part, vous devez être conscient que si superviseur est vulnérable à un bug qui provoque l'exécution du code, un user malveillant pourrait utiliser ce privilège sudo pour exécuter le code en tant que root (mais pour autant que je sache, aucun bug n'a été découvert pour le superviseur et C'est une grande chose pour find une telle vulnérabilité).

J'ai trouvé les scripts init.d fiables sur une variété de différentes versions Ubuntu / Debian. La façon de le faire est la suivante:

 sudo supervisorctl reload 

Faites attention aux liens symboliques et incluez les files sur Supervisor. Cela permettrait à toute personne avec privilège w sur /home/myapp/live/deploy/supervisord_live.ini de modifier le file ini et de commencer tout code malveillant. Ces files ini devraient être dans le directory conf de votre superviseur ou dans n'importe quel sous-directory sous celui-ci.

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

Vous pouvez voir que la mise à jour de superviseur (fonction do_update) appelle reloadConfig () exactement comme la relève superviseur (fonction do_reread) le fait.

Je pense donc que l'appel de relève n'est pas nécessaire si vous appelez la mise à jour après.

De la production de git blame, c'est comme ça depuis au less depuis juillet 2009.

J'avais installé supervision avec l'installation de yum, qui a installé le superviseur de la version v2. *. Superviseur prend en charge les inclusions externes uniquement à partir de la version 3. A la place, il faut utiliser easy_install pour installer supervisor v3.

Voici une list de contrôle:

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

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

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

  2. Si vous avez créé le nouveau file en copiant un ancien, assurez-vous de modifier réellement la ligne [program:] . Si vous êtes aussi stupide que d'avoir deux files pour le même programme, la supervisorctl reread vous laissera ce message d'erreur sans espoir:

     No config updates to processes 
  3. Si votre file est détecté, la supervisorctl reread doit indiquer quelque chose comme:

     spam: available 
  4. Ensuite, le supervisorctl update spam doit commencer et créer supervisorctl status .