web-dev-qa-db-fra.com

Comment puis-je m'assurer qu'un travail Upstart commence avant d'autres travaux Upstart?

C'est une question générale d'Upstart, mais laissez-moi utiliser un cas spécifique:

Centrify est une passerelle NIS vers ActiveDirectory. Il doit être chargé avant tout service dépendant du service d'authentification fourni, par exemple. autofs, cron, nis et al.

Cela s'est avéré assez difficile à réaliser, même en essayant de changer les dépendances des autres services (ce que je ne pense pas que nous devrions faire de toute façon, je ne veux pas toucher les autres emplois Upstart si possible) .

Suggestions?

bootupstartinit
33
Mark Russell

La réponse de James fonctionne pour une dépendance de 1 à 1. Pour un 1 à plusieurs, c’est-à-dire, pour vous assurer que le service A commence avant les services B, C et D, vous devez adopter une autre approche. Vous pouvez consulter les scripts portmap actuels à titre de référence, mais voici l’approche générale: créer un script d’attente.

Scénario: vous voulez que votre service A toujours s'exécute avant service-b, service-c et service-d.

Solution: créez un script d'attente pour le service A. Appelez-le "/etc/init/service-a-wait.conf".

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

En clair, cela signifie: lorsque le service b, c ou d indique qu’il souhaite démarrer, il doit attendre que le service-a soit lancé. Le travail service-a-wait est conçu pour s'exécuter jusqu'à ce que le service-a ait démarré. Une fois que service-a-wait est terminé, les services b, c et d sont désormais libres de fonctionner.

Cela garantira que le service-a est opérationnel avant toute tentative de démarrage de ses dépendances inverses.

Remarque: la ligne "instance $ JOB" est importante dans ce scénario "démarrer le ... ou .. ou ..". Autrement, vous ne bloquerez que pour n'importe lequel des groupes B, C ou D qui se déclenche en premier.

(L’instanciation mérite honnêtement une meilleure explication. Pour le moment, faites-le.;)

12
Mark Russell

La solution consiste à aborder le problème de l’autre côté: pour satisfaire aux critères de démarrage de Centrify, il n’est pas nécessaire de faire dépendre les services existants du nouveau service Centrify, mais plutôt de faire dépendre le nouveau service Centrify des services existants.

Par exemple, un fichier de configuration Upstart /etc/init/centrify.conf pourrait indiquer:

démarrer sur (démarrer cron ou démarrer autofs ou démarrer nis)

En convertissant cela en anglais, cela se traduirait par:

démarrez le service Centrify juste avant soit cron, autofs ou nis start (selon le premier début).

L'ordre dans lequel cron, autofs ou nis start n'est pas important: Upstart s'assurera que Centrify démarrera avant le service choisi en premier, assurant ainsi qu'il s'exécute avant le démarrage de l'un de ces services.

Notez également que Upstart bloque le démarrage du premier service qui veut démarrer tant que Centrify n’est pas encore lancé.

Très élégant et simple une fois que vous vous habituez à penser de cette manière.

29
James Hunt