web-dev-qa-db-fra.com

Comment fonctionne le travail rc / ordre (contradictoire) des strophes "démarrer le ..." et "arrêter le ..."

Je ne comprends tout simplement pas comment fonctionne la définition de travail rc d'Upstart dans Natty 11.04. Pour illustrer le problème, voici la définition (les lignes vides et les commentaires sont omis):

start on runlevel [0123456]
stop on runlevel [!$RUNLEVEL]
export RUNLEVEL
export PREVLEVEL
console output
env INIT_VERBOSE
task
exec /etc/init.d/rc $RUNLEVEL

Supposons que nous soyons actuellement au niveau d'exécution 2 et que le travail rc soit arrêté (c'est exactement la situation après le démarrage de ma box et la connexion via SSH). Supposons maintenant que le système passe au niveau d'exécution 3, par exemple en raison d'une commande comme "telinit 3" donnée par root. Qu'adviendra-t-il du travail rc?

De toute évidence, le travail rc sera démarré car il est actuellement arrêté et l'événement runlevel 3 correspond aux événements de démarrage. Mais à partir de maintenant, les choses ne sont pas claires pour moi: selon le manuel, $ RUNLEVEL évalue le nouveau niveau d'exécution lorsque le travail est démarré (cela signifie 3 dans notre exemple).

Par conséquent, la strophe suivante "stop on runlevel [! $ RUNLEVEL]" se traduit par "stop on runlevel [! 3]"; cela signifie que nous avons une première strophe qui déclenchera le travail, mais la deuxième strophe n'arrêtera jamais le travail et semble inutile.

Puisque je sais que les gens d'Ubuntu/Upstart ne feront pas de choses inutiles, je dois mal comprendre quelque chose. Je serais reconnaissant pour toute explication.

Tout en essayant de comprendre cela, une question supplémentaire m'est venue à l'esprit. Si j'avais des déclencheurs de démarrage et d'arrêt contradictoires, par exemple

start on foo
stop on foo

ce qui se passerait? Je jure que je ne le ferai jamais, mais je suis néanmoins très intéressé par la façon dont Upstart gère cela au niveau théorique.

Merci beaucoup!

Modification de la question en réaction à la première réponse du geekosaure:

Je peux voir le parallélisme, mais ce n'est pas si facile (du moins, pas pour moi).

Supposons que le travail soit toujours en cours d'exécution et qu'un nouvel événement de niveau d'exécution arrive (bien sûr, le nouveau niveau d'exécution est différent de l'actuel). Ensuite, les événements suivants devraient se produire:

1) Le travail est à instance unique. Cela signifie que "démarrer le ..." ne sera pas déclenché car le travail est en cours d'exécution; $ RUNLEVEL n'est pas touché.

2) "stop on ..." sera déclenché car le niveau d'exécution nouvea est différent de $ RUNLEVEL, donc la tâche sera abandonnée.

3) Maintenant, le travail est arrêté et en attente. Je ne vois pas comment il est redémarré avec le niveau d'exécution nouvea. AFAIK, initctl n'émet les événements qu'une seule fois, donc "start on ..." ne sera pas déclenché et le nouveau niveau d'exécution ne sera pas entré.

Je sais que je ne comprends toujours pas quelque chose, et je suis reconnaissant pour les explications.

Merci beaucoup!

evolutionupstartsystem
3
Binarus

L'ordre des opérations est très soigneusement maintenu dans upstart lors du traitement des événements. Les arrêts provoqués par un événement sont toujours effectués avant les démarrages. Bien que Linux soit multi-processus, le moteur d'événements d'Uststart ne l'est pas.

Ainsi, la commande runlevel, qui émet l'événement 'runlevel', est reçue par le moteur d'état upstart, puis traitée en effectuant d'abord toutes les transitions du début à l'arrêt complètement. Cela bloquera jusqu'à ce que le premier rc soit tué et mort. Ensuite, les transitions de l'arrêt au démarrage sont effectuées et le nouveau travail rc est démarré.

Ceci est en fait documenté dans le code source parvenu:

    /* We stop first so that if an event is listed both as a
     * stop and start event, it causes an active running process
     * to be killed, the stop script then the start script to be
     * run.  In any other state, it has no special effect.
     *
     * (The other way around would be just strange, it'd cause
     * a process's start and stop scripts to be run without the
     * actual process).
     */

Cela appartient probablement au livre de recettes par défaut , j'ai donc ouvert un bogue de liste de souhaits ici:

https://bugs.launchpad.net/upstart-cookbook/+bug/745096

3
SpamapS

Nous avons maintenant documenté (espérons-le) clairement comment fonctionne le travail "rc" dans Ubuntu dans le livre de recettes Upstart. Il a même sa propre section:

http://upstart.ubuntu.com/cookbook/#the-rc-job

Cependant, pour le contexte complet, je vous suggère de lire à partir d'ici:

http://upstart.ubuntu.com/cookbook/#really-understanding-start-on-and-stop-on

3
jamesodhunt

Le reste de votre question devrait maintenant être répondu par les sections suivantes dans le livre de recettes Upstart:

3
jamesodhunt

Avez-vous vu ma réponse à Sens de la strophe "Stop on ..." lorsque le travail est une tâche ? La même réponse s'applique à la première partie de votre question, elle est utilisée pour abandonner le démarrage du niveau d'exécution si l'utilisateur passe à un autre niveau d'exécution avant la fin.

Je n'ai cependant aucune idée de la deuxième partie.

1
geekosaur