Comment démarrer et arrêter une unité systemd avec une autre?


20

J'utilise CoreOS pour planifier les unités systemd avec la flotte. J'ai deux unités ( firehose.serviceet firehose-announce.service. J'essaie d'obtenir le firehose-announce.servicedémarrage et l'arrêt avec le firehose.service. Voici le fichier d'unité pour firehose-announce.service:

[Unit]
Description=Firehose etcd announcer
BindsTo=firehose@%i.service
After=firehose@%i.service
Requires=firehose@%i.service

[Service]
EnvironmentFile=/etc/environment
TimeoutStartSec=30s
ExecStartPre=/bin/sh -c 'sleep 1'
ExecStart=/bin/sh -c "port=$(docker inspect -f '{{range $i, $e := .NetworkSettings.Ports }}{{$p := index $e 0}}{{$p.HostPort}}{{end}}' firehose-%i); echo -n \"Adding socket $COREOS_PRIVATE_IPV4:$port/tcp to /firehose/upstream/firehose-%i\"; while netstat -lnt | grep :$port >/dev/null; do etcdctl set /firehose/upstream/firehose-%i $COREOS_PRIVATE_IPV4:$port --ttl 300 >/dev/null; sleep 200; done"
RestartSec=30s
Restart=on-failure

[X-Fleet]
X-ConditionMachineOf=firehose@%i.service

J'essaie d'utiliser BindsToavec la notion que le démarrage et l'arrêt de firehose.servicedémarreront ou s'arrêteront également firehose-announce.service. Mais cela ne se produit jamais correctement. Si firehose.serviceest arrêté, firehose-announce.servicepasse à l'état d'échec. Mais quand je commence firehose.service, le firehose-announce.servicene démarre pas.

Qu'est-ce que je fais mal ici?


Même problème ici. Avez-vous trouvé une solution?
nahime

Réponses:


24

Il semble que je sois finalement tombé sur la bonne combinaison pour que cela fonctionne comme souhaité.

Dans mon firehose-announce.serviceunité, je n'ai défini qu'un BindsTo. L'unité entière est:

[Unit]
Description=Firehose etcd announcer
BindsTo=firehose@%i.service

[Service]
EnvironmentFile=/etc/environment
TimeoutStartSec=30s
ExecStartPre=/bin/sh -c 'sleep 1'
ExecStart=/bin/sh -c "port=$(docker inspect -f '{{range $i, $e := .NetworkSettings.Ports }}{{$p := index $e 0}}{{$p.HostPort}}{{end}}' firehose-%i); echo -n \"Adding socket $COREOS_PRIVATE_IPV4:$port/tcp to /firehose/upstream/firehose-%i\"; while netstat -lnt | grep :$port >/dev/null; do etcdctl set /firehose/upstream/firehose-%i $COREOS_PRIVATE_IPV4:$port --ttl 300 >/dev/null; sleep 200; done"
RestartSec=30s
Restart=on-failure

[X-Fleet]
X-ConditionMachineOf=firehose@%i.service

Cela entraînera l' firehose-announce.servicearrêt de l' unité lorsque firehose.servicecela se produit. Génial. Mais comment recommencer?

J'inverse la dépendance d'être dans mon firehose.serviceunité comme ceci:

[Unit]
Description=Firehose server
Wants=firehose-announce@%i.service
Before=firehose-announce@%i.service

[Service]
ExecStartPre=/usr/bin/docker pull firehose/server
ExecStartPre=-/usr/bin/docker rm -f firehose-%i
ExecStart=/usr/bin/docker run --name firehose-%i -p 7474 --env-file /home/core/firehose.env firehose/server
ExecStop=/usr/bin/docker rm -f firehose-%i
User=core
TimeoutStartSec=5m
TimeoutStopSec=20s
RestartSec=30s
Restart=on-failure

[Install]
WantedBy=multi-user.target

[X-Fleet]
X-Conflicts=firehose@*.service

Cela veut dire qu'il firehose.serviceveut firehose-announce.servicedémarrer quand il le fait (mais n'échoue pas s'il firehose-announce.servicene peut pas démarrer). Il s'assure également que firehose.servicecommence avant firehose-announce.service.

J'ai testé cela et les unités semblent maintenant s'arrêter et démarrer ensemble comme souhaité.


Génial, je vais l'essayer.
nahime

1
Apparemment, veut = signifie facultatif. Requiert = est une exigence. BindsTo signifie que si la dépendance, c'est-à-dire le service d'incendie s'arrête, le service d'annonce d'incendie est également considéré comme arrêté. Cela me semble une bonne chose.
Matt

Est-il possible d'obtenir ce comportement sans toucher à firehouse.service?
buddy123

J'ai essayé cette solution, mais je rencontre un problème. J'ai le service A avec Requiert = B.service et le service B avec BindsTo = A.service. Lorsque A se ferme anormalement, je vois A et B redémarrer. Mais quand A se termine avec le code 0 / SUCESS, les deux restent à l'état arrêté
Bug Killer

ExecStartPre = {dash} -ne sert à rien sur le dernier et ne sert à rien sur tout sauf le dernier ExecStartPre
meffect
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.