Le superviseur ne charge pas les nouveaux fichiers de configuration

68

J'ai un problème lors du déploiement de l'application Django avec Gunicorn et Supervisor. Bien que je puisse faire en sorte que Gunicorn serve mon application (en définissant PYTHONPATH correctement et en exécutant une commande appropriée, celle de Supervisord config), je ne peux pas demander à un superviseur de l'exécuter. Il ne veut tout simplement pas voir mon application. Je ne sais pas comment m'assurer que le fichier de configuration est correct.

Voici ce que dit supervisorctl:

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

Je l’utilise sous 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 fichier, il y a:

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

et voici un lien symbolique vers mon fichier 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 aller pour moi mais supervisorctl ne cesse de le dire myapp_live: ERROR (no such process). Une solution pour ça?

grucha
la source
Je me grattais la tête avec le même problème; mes fichiers de configuration n'étaient pas chargés lorsque j'ai exécuté rereadou update. Il s’est avéré que j’avais sauvegardé mes fichiers de configuration foo.conf.pyplutôt que de les foo.confidentifier.
Timmy O'Mahony

Réponses:

31

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

sudo service supervisord reload

fait le tour, mais je ne sais pas si c'est la réponse à votre question.

Hixi
la source
2
J'ai arrêté puis commencé superviseur il y a quelque temps et cela a fonctionné. Je ne sais pas si le rechargement fonctionnerait (comme le redémarrage de mon coeur ne le fait pas) mais j'imagine que cela pourrait
grucha
Je l'ai fait aussi et ça a marché. Je me demande pourquoi /etc/init.d/supervisor restartne fonctionne pas quand l'arrêt manuel et le début font.
Kirill
1
Travaillé pour moi, bien que le service ne fonctionnait pas si je viens de rencontrer ps aux | grep supervisor, puissudo kill -HUP pid
Wayne Werner
2
Ceci est dangereux car il va redémarrer tout le démon superviseur.
Mark Theunissen
7
supervisorctl relire peut résoudre ce problème sans redémarrer le service.
Jonathan Liuti
199

La bonne réponse est que le superviseur vous demande de relire et de mettre à jour lorsque vous placez un nouveau fichier de configuration. Le redémarrage n'est pas la solution, car cela affectera d'autres services. Essayer:

supervisorctl reread
supervisorctl update
Mark Theunissen
la source
13
Cela devrait être la bonne réponse. "Relire le superviseur" ne suffit pas.
Miebster
3
+1 C'est une meilleure réponse car elle ne repose pas sur des gestionnaires de processus.
Tidwall
8
La "relecture de supervisorctl" ne suffit pas à elle seule, mais la "mise à jour de supervisorctl" ne serait-elle pas suffisante? Selon la documentation, "update" effectue une relecture suivie d'un redémarrage des programmes dont la configuration a été modifiée par la relecture.
BlueBomber
Ça marche pour moi J'ai redémarré après.
user1012513
15

Assurez-vous que vos fichiers de configuration de superviseur se terminent par .conf

Il m'a fallu un certain temps pour comprendre celui-là. Espérons que cela aide la personne suivante.

non
la source
1
Gâché une heure sur le même problème - ne peux pas croire que c'était aussi simple.
Zane Hooper
1
Merci d'avoir énuméré cette réponse. Pour ma vie, je ne pouvais pas comprendre celui-ci.
Phillip Martin
14

Le rechargement du processus de superviseur principal peut fonctionner, mais il aura des effets secondaires inattendus si plusieurs processus sont surveillés par le superviseur.

La bonne façon de le faire est d'émettre supervisorctl rereadce qui l'amène à analyser les fichiers de configuration pour tout changement:

root@debian:~# supervisorctl reread
gunicorn: changed

Ensuite, rechargez simplement cette application:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started
Burhan Khalid
la source
C'est la meilleure solution si vous voulez uniquement lire un fichier de configuration modifié / nouveau et laisser le reste des processus en cours intact. Supervisorctl montrera que la nouvelle application est avail. Ajoutez-le aux processus (re) démarrables en émettant supervisorctl update. Voir aussi la réponse de Mark serverfault.com/a/479754/125887
Sjaak Trekhaak Le
4
Ce n'était pas assez pour moi. supervisorctl updateétait nécessaire.
Yaroslav Nikitenko
5

J'ai rencontré ce problème en utilisant le paquet superviseur, 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 indiqué dans la documentation à l' adresse http://supervisord.org/configuration.html#programx-section - "Une section [programme: x] représente en réalité un" groupe de processus homogène "pour le superviseur (à partir de la version 3.0)." Alors peut-être que le problème est apparu pour la première fois 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 ce à quoi une configuration minimale devrait ressembler.

picomancien
la source
4

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

[program: myapp_live]

quand cela aurait dû être

[program:myapp_live]

Bien que cela ne réponde pas à la question qui a été posée, j'ai été amené ici par le groupe Recherche qui cherche à trouver une solution à mon problème. J'espère donc que d'autres personnes le trouveront également ici.

Conrad.Dean
la source
Pareil ici! Je l'avais laissé en tant [program]que seul, en suivant les documents, mais en le faisant [program:redis]fonctionner pour moi. Les choses deviennent parfois bizarres!
ankush981
2

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

EDIT: avant de faire cela, vérifiez votre chemin supervisorctl en utilisant which supervisorctlpour vous assurer que vous ajoutez le bon chemin aux 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 simplement:

sudo supervisorctl restart myapp

Vous n'êtes pas lié aux scripts de démarrage de la distribution et vous accordez des privilèges très limités à l'utilisateur qui redémarre votre application gunicorn. En outre, vous n'avez pas besoin de vous soucier de pid. La commande ne demandera pas de mot de passe, elle convient donc aux scripts bash / fabric à déploiement automatique. D'autre part, vous devez savoir que si supervisorctl est vulnérable à un bogue entraînant l'exécution de code, un utilisateur malveillant pourrait utiliser ce privilège sudo pour exécuter du code en tant que root (mais, à ma connaissance, aucun bogue n'a été découvert pour supervisord et c'est une grande chose de trouver une telle vulnérabilité).

Pielgrzym
la source
2

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 supervisorctl (fonction do_update) appelle reloadConfig () exactement comme le fait le relecteur supervisorctl (fonction do_reread).

Donc, je pense qu’appeler relire n’est pas nécessaire si vous appelez update après.

Depuis la sortie de blâme, c’est comme ça depuis au moins juillet 2009.

Sébastien Estienne
la source
2

Voici une liste de contrôle:

  1. Le nouveau fichier de configuration doit être nommé en fonction du 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, assurez-vous de changer la [program:]ligne. Parce que si vous êtes aussi stupide que d'avoir deux fichiers pour le même programme, supervisorctl rereadce message d'erreur sans espoir vous laissera comme punition:

    No config updates to processes
    
  3. Si votre fichier est détecté, supervisorctl rereaddevrait dire quelque chose comme:

    spam: available
    
  4. Ensuite, les supervisorctl update spamdeux doivent le démarrer et le faire apparaître dans supervisorctl status.

utilisateur2394284
la source
1

J'ai constaté que les scripts init.d n'étaient pas fiables sur différentes versions d'Ubuntu / Debian. La façon de le faire est la suivante:

sudo supervisorctl reload
mafrose
la source
Ce n'est pas la bonne façon de le faire, bien que cela fonctionne dans de nombreuses circonstances. @ burhan-khalid answer est la bonne, et fournit une explication à cela.
Glarrain
1

Soyez prudent avec les liens symboliques et inclure des fichiers sur Supervisor. Cela permettrait à toute personne ayant le privilège w sur /home/myapp/live/deploy/supervisord_live.ini de modifier le fichier ini et de lancer tout code malveillant. Ces fichiers ini doivent se trouver dans le répertoire conf de votre superviseur ou dans l'un des sous-répertoires qu'il contient.

Leo Pepe
la source
0

J'avais installé supervisrod avec yum install, qui a installé le superviseur de la version v2. *. Supervisor prend en charge les inclusions externes uniquement à partir de la version 3. Doit utiliser easy_install à la place pour installer Supervisor v3.

Aidas
la source
C'était aussi mon problème, cela se produira probablement sur toutes les installations Centos 6.5 ou moins.
bearrito