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 autres.

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?

boot upstart init

— Mark Russell
source

Réponses:

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.confpourrait 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 cron, autofs ou nis start (celui qui commence en premier).

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.

— James Hunt
source

cela me semble totalement en arrière. pourquoi devrait être modifié le script pour un service conf quand d' autres choses dépendent de ce ?

— ben w

@benw Pour ne pas avoir à modifier les paramètres existants des services que vous ne possédez pas.

— Paccc

@Paccc lorsque j'écris un nouveau script qui dépend de nginx, je dois modifier le script conf pour nginx ... que je ne possède pas.

— ben w

@benw Pourquoi ne pouvez-vous pas utiliser start on (started nginx)dans votre nouveau script?

— Paccc

@ Paccc pas vraiment. start on (started nginx)signifie "commencer mon service après nginx". Ce qui n’est pas la même chose que "démarre nginx avant mon service car il en a besoin".

— sickill

La réponse de James fonctionne pour une dépendance de 1 à 1. Pour un 1 sur 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 pour référence, mais voici l’approche générale: créer un script d’attente.

Scénario: vous voulez que votre service A soit toujours exécuté 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 exécuté. 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.;)

— Mark Russell
source

Je ne comprends pas cela… Qu'est-ce qui empêche une situation critique entre le démarrage du service A et le service B qui continue à démarrer? Je ne vois pas comment upstart saura que le script a terminé "start service-a" ... (blâmez peut-être la documentation de mauvaise qualité d'Upstart ...)

— Chris Pacejo

@ Mark Russell: cette normal exit 2ligne ne devrait-elle pas être à la normal exit 0 2place? La première ligne de la scriptsection peut très clairement exit 0.

— Depuis