Supervisor: Différences entre relire, recharger, redémarrer, mettre à jour ?

Créé le 13 févr. 2016  ·  30Commentaires  ·  Source: Supervisor/supervisor

Peut-être que je l'ai raté, mais y a-t-il une bonne explication quelque part sur les différences entre ces quatre commandes ? Je ne les ai pas vus discutés dans la documentation en ligne de superviseur. J'ai remarqué sur ServerFault et Stackoverflow que d'autres utilisateurs ne comprennent pas non plus leurs différences.

Par exemple, si je change la configuration dans une section de programme, je sais que je dois faire "supervisorctl relire" pour que ces modifications soient disponibles. Mais comment redémarrer uniquement ce programme ? redémarrage superviseurctlne fonctionne pas. Au lieu de cela, s'il apparaît que vous devez exécuter "supervisorctl update" ou redémarrer le démon superviseur lui-même. Cependant, cela semble avoir pour effet involontaire de redémarrer tous les programmes, pas seulement celui qui a changé.

Merci.

docs

Commentaire le plus utile

Les définitions suivantes fonctionneraient-elles pour la documentation ?

relire - Relire la configuration du superviseur. Ne mettez pas à jour ou ne redémarrez pas les services en cours d'exécution.
update - Redémarrez le(s) service(s) dont la configuration a changé. Généralement exécuté après 'relecture'.
reload - Relire la configuration du superviseur, recharger supervisord et supervisorctl , redémarrer les services qui ont été démarrés.
redémarrer - Redémarrer le(s) service(s)

Tous les 30 commentaires

Peut-être que je l'ai raté, mais y a-t-il une bonne explication quelque part sur les différences entre ces quatre commandes ?

Non, cela devrait être ajouté à la documentation. J'ai ajouté l'étiquette docs et je laisserai ce problème ouvert pour que nous le fassions.

Je trouve toujours que la documentation actuelle est déroutante.

Merci, mon ami.

Le mar. 13 décembre 2016 à 7h35, Paweł Adamczak [email protected]
a écrit:

Ce qui m'a aidé - http://www.onurguzel.com/supervisord-restarting-and-
rechargement/


Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Supervisor/supervisor/issues/720#issuecomment-266770482 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEgNpM6R9BMwE03q_DejU96qUOef8zCtks5rHrtMgaJpZM4HZsaj
.

@flaugher Je pense toujours qu'il vaut la peine de garder ce problème ouvert, car la documentation ne contient toujours pas les informations pertinentes.

En fait, je prévoyais d'envisager de faire un PR le week-end.

Si vous voulez le rouvrir, allez-y. Je n'ai rien vu de nouveau et j'ai dépassé le problème et je ne voulais pas continuer à recevoir des notifications. Je n'arrivais pas à comprendre comment le couper, alors je l'ai fermé.

Le 13 décembre 2016, à 16h03, Paweł Adamczak [email protected] a écrit :

@flaugher Je pense toujours qu'il vaut la peine de garder ce problème ouvert, car les documents n'ont toujours pas les informations.

En fait, je prévoyais d'envisager de faire un PR le week-end.


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

En tant que non membre du projet ou créateur de problème, je ne peux pas l'ouvrir, mais je comprends parfaitement votre point de vue.

BTW - Pour autant que je sache, vous pouvez vous désabonner des notifications dans le menu de droite en mode problème

Enfin - désolé pour le spam :-)

Salut à tous.

À mon humble avis, je suis d'accord avec la réouverture de ce problème.

Bien que la doc ci-dessous puisse éclairer la question, elle semble un peu vague en ce qui concerne les définitions.

Concernant l'action "mise à jour", je pense qu'il y a plus de choses à décrire ou à mieux décrire, par exemple.

Voici le scénario : lorsque vous créez une configuration pour un processus à gérer par "supervisord", vous lancez "supervisorctl update" puis vient le message "your_configured_process: added process group". Existe-t-il un type de groupe contrôlé par "supervisord", qui doit contenir un enregistrement précisant que votre processus est désormais géré par "supervidord" ?

Lors de mes dernières recherches sur Google, j'ai également trouvé cette page de manuel sur le site Web d'Ubuntu, et elle ne semble pas avoir d'explications pour les actions de superviseur.

Quelqu'un (membre du projet) peut-il rouvrir ce problème ? Il semble que je ne sois pas le seul à croire que cela doit être fait.

Merci
@ivanleoncz

Alors où la réponse ?

+1 pour la réouverture. reread|reload|restart|update sont toujours sans papiers.

Salut, désolé d'être ce type, mais, pourrions-nous rouvrir ce problème ? Merci.

@pawelad En quoi cela vous a-t-il aidé ? La deuxième phrase est carrément fausse.

Cependant, il n'a pas d'option de rechargement.

Le superviseur a très certainement une option reload ...

Encore quelqu'un d'autre ici qui apprécierait vraiment une documentation _utilisable_...

Wow. Je ne peux pas croire que ce problème existe. Merci @ivanlmj pour les liens informatifs.

De rien, @cornfeedhobo . Merci de vous préoccuper de ce problème :).

Quelqu'un s'il vous plaît expliquer l'action reload : ce que j'attends de celui-ci est essentiellement un reread + update . C'est ça le comportement actuel ?

Ce n'est certainement pas le cas, mais on pourrait le croire ! Man quelques docs mis à jour seraient super en ce moment ....

@mnaberez pouvons-nous avoir une définition claire de chacun de ces termes ?
Si vous pouvez les détailler ici, je serais heureux de faire une pull request aux docs.

Les définitions suivantes fonctionneraient-elles pour la documentation ?

relire - Relire la configuration du superviseur. Ne mettez pas à jour ou ne redémarrez pas les services en cours d'exécution.
update - Redémarrez le(s) service(s) dont la configuration a changé. Généralement exécuté après 'relecture'.
reload - Relire la configuration du superviseur, recharger supervisord et supervisorctl , redémarrer les services qui ont été démarrés.
redémarrer - Redémarrer le(s) service(s)

Pas mal!
Avez-vous certifié que ce sont les vrais aspects de chaque action, @ocervell ? Si vous en êtes sûr, ce serait bien d'envoyer un PR pour la documentation ! Je dis juste :) ! Merci!

J'ai essayé de relire et de mettre à jour superviseurctl, et j'ai trouvé que 'mise à jour' ne faisait que le travail de relecture: recharger la configuration de l'application. alors quel est le besoin de l'action 'relire' ? j'ai trouvé confus

$ supervisorctl help update
update          Reload config and add/remove as necessary, and will restart affected programs
update all      Reload config and add/remove as necessary, and will restart affected programs
update <gname> [...]    Update specific groups

Donc reread n'est pas nécessaire ?

Je trouve ça encore un peu confus. Actuellement, j'exécute update et restart all sur une mise à jour de notre logiciel. Cela pourrait être :

  • Un fichier de configuration du superviseur est modifié
  • Un script est modifié et nécessite un redémarrage.

Mais lorsqu'une configuration de superviseur est mise à jour, le script est relancé deux fois (car update et restart all ). J'ai également essayé reread et restart all , mais dans ce cas, les nouveaux fichiers de configuration n'ont pas démarré automatiquement.

Existe-t-il une commande ou une combinaison de commandes qui rechargera tous les fichiers de configuration et redémarrera tous les scripts sans les redémarrer deux fois et charger et démarrer de nouveaux fichiers de configuration trouvés ?

Personne sur la question de @Wouter0100 ?

@ Wouter0100 Considérant que vous "redémarrez tout", ce que vous voulez pourrait être mieux accompli par un "realod", bien que d'une manière légèrement différente :
Reload arrêtera le démon superviseur, rechargera la configuration puis redémarrera le démon. En supposant que vos processus aient autostart=true (valeur par défaut), tout sera redémarré exactement une fois.

Si vous avez besoin de quelque chose de moins rapide, je crains que vous n'ayez pas de chance : la relecture ne démarrera pas les nouveaux processus trouvés (comme vous l'avez remarqué) et la mise à jour ne redémarrera que si la configuration change, et elle ne redémarrera pas les processus (par exemple) dont (supervisord ) config est resté le même, mais dont l'exécutable a changé pour une nouvelle version.

J'ai posté une autre solution au #1264.

@AlekSi n'est pas vraiment une solution, car cela nécessite de spécifier chaque fichier individuellement.

Eh bien, cela dépend de votre cas d'utilisation. Dans mon cas, cette tâche Ansible fonctionne :

    - name: Restart services
      command: supervisorctl {{ item.1 }} {{ item.0 }}
      with_nested:
        - ['x', 'y', 'z']
        - ['stop', 'remove', 'add']

Questions postées sur le numéro 1264 en double :

C'est en quelque sorte une suite du #720 qui est fermé mais contient des commentaires de beaucoup de personnes confuses.

Mon problème

Je dois redémarrer le service X exactement une fois après la mise à jour de son package. Il contient le service binaire et une partie de la configuration de superviseur qui est include -ed à partir du fichier principal.

Mes tentatives

1. `supervisorctl update` does not restart service if configuration file did not change, old binary is still running.

2. `supervisorctl restart` restarts service with the old configuration, the new configuration is not used.

3. `supervisorctl reread && supervisorctl restart` does the same as the one above – and that is very surprising!

4. `supervisorctl update && supervisorctl restart` restarts service twice if configuration file changed.

Ma solution

supervisorctl reread

supervisorctl stop X
supervisorctl remove X
supervisorctl add X  # that also starts X as I have `autostart = true` in configuration

Ça marche. Mais est-ce vraiment le meilleur moyen ?
Et pourquoi la tentative 3 n'a pas fonctionné ?

Ça marche. Mais est-ce vraiment le meilleur moyen ?

Oui

Et pourquoi la tentative 3 n'a pas fonctionné ?

La commande reread oblige supervisord à relire le fichier de configuration et à prendre connaissance des modifications, mais elle n'applique aucune de ces modifications à la configuration active. Les commandes remove et add sont utilisées pour appliquer ces modifications à la configuration active.

Cette page vous a été utile?
0 / 5 - 0 notes