web-dev-qa-db-fra.com

Le superviseur ne charge pas de nouveaux fichiers de configuration

J'ai un problème de déploiement de l'application Django utilisant Gunicorn et Supervisor. Bien que je puisse faire en sorte que Gunicorn serve mon application (en définissant le PYTHONPATH approprié et en exécutant une commande appropriée, celle de la configuration de supervord), je ne peux pas faire superviseur pour l'exécuter. Il ne verra tout simplement pas mon application. Je ne sais pas comment m'assurer que le fichier de configuration est correct.

Voici ce que supervorctl 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 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 me va bien mais supervisorctl continue de dire myapp_live: ERROR (no such process). Une solution pour ça?

deploymentsupervisordgunicorn
75
grucha

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.

35
Hixi

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

supervisorctl reread
supervisorctl update
209
Mark Theunissen

Assurez-vous que les fichiers de conf de votre superviseur se terminent par .conf

Cela m'a pris un certain temps pour comprendre celui-là. Espérons que cela aide la prochaine personne.

17
nym

Le rechargement du processus du superviseur principal peut fonctionner, mais cela aura des effets secondaires imprévus si plusieurs processus sont surveillés par le superviseur.

La façon correcte de le faire est d'émettre supervisorctl reread ce qui oblige à 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
14
Burhan Khalid

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 il aurait dû être

[program:myapp_live]

Bien que cela ne réponde pas à la question qui a été posée, j'étais dirigé ici par la recherche qui cherche une solution à mon problème, alors j'espère que d'autres personnes la trouveront ici aussi.

5
Conrad.Dean

J'ai rencontré ce problème en utilisant le package 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 souhaitez utiliser la syntaxe:

Sudo supervisorctl restart myapp_live:*

Comme l'indique la documentation à 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 3.0). " Alors peut-être que le problème est apparu en premier 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 devrait ressembler une configuration minimale.

5
picomancer

Lecture du code de supervisorctl.py ici: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Vous pouvez voir que la mise à jour de supervorctl (fonction do_update) appelle reloadConfig () exactement comme le fait la relecture de supervorctl (fonction do_reread).

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

De la sortie de git blame, il en est ainsi depuis au moins depuis juillet 2009.

2
Sebastien Estienne

J'ai trouvé cette solution la plus pratique:

EDIT: avant de faire cela, vérifiez votre chemin supervisorctl en utilisant which supervisorctl pour 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 assez étroits à l'utilisateur qui redémarre votre application gunicorn. De plus, 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'un autre côté - vous devez être conscient que si supervisorctl est vulnérable à un bug provoquant l'exécution de code, un utilisateur malveillant pourrait utiliser ce privilège Sudo pour exécuter le code en tant que root (mais pour autant que je sache, un tel bug n'a pas été découvert pour supervisord et c'est une grande chose de trouver une telle vulnérabilité).

2
pielgrzym

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 modifier réellement le [program:] ligne. Parce que si vous êtes aussi stupide que d'avoir deux fichiers pour le même programme, supervisorctl reread vous laissera ce message d'erreur sans espoir comme punition:

    No config updates to processes

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

    spam: available

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

2
user2394284

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

Sudo supervisorctl reload
1
mafrosis

Soyez prudent avec les liens symboliques et incluez les fichiers sur Supervisor. Il permettrait à toute personne disposant du privilège w sur /home/myapp/live/deploy/supervisord_live.ini de modifier le fichier ini et de démarrer tout code malveillant. Ces fichiers ini doivent se trouver dans le répertoire conf de votre superviseur ou dans n'importe quel sous-répertoire en dessous.

1
Leo Pepe

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

0
Aidas