Comment redémarrer un service si son service dépendant est redémarré
Un service (disons bar.service) dépend d'un autre service (disons foo.service), comme ci-dessous
fiche de service du bar:
[Unit]
After=foo.service
Requires=foo.service
...
Si foo.service est redémarré (manuellement ou à cause d'un bogue), comment redémarrer automatiquement bar.service?
Vous pouvez utiliser PartOf.
[Unit]
After=foo.service
Requires=foo.service
PartOf=foo.service
De la page de manuel systemd.unit:
PartOf =
Configure les dépendances similaires à Requis =, mais limitées à l’arrêt et au redémarrage des unités. Lorsque systemd arrête ou redémarre les unités répertoriées ici, l'action est propagée à cette unité. Notez qu'il s'agit d'une dépendance à sens unique - les modifications apportées à cette unité n'affectent pas les unités répertoriées.
Je pense que l'option nécessaire est BindsTo, elle corrige également les problèmes de comportement.
[Unit]
Requires=postgresql.service
After=postgresql.service
BindsTo=postgresql.service
BindsTo =
Configure les dépendances d’exigences, dont le style est très similaire à celui de Requiert =. Cependant, ce type de dépendance est plus fort: en plus de l'effet de Requis =, il déclare que si l'unité liée à est arrêtée, cette unité sera également arrêtée. Cela signifie qu'une unité liée à une autre unité qui entre soudainement dans un état inactif sera également arrêtée. Des unités peuvent soudainement et inopinément entrer dans un état inactif pour différentes raisons: le processus principal d’une unité de service peut s’arrêter de son propre choix, le périphérique de support d’une unité peut être débranché ou le point de montage d’une unité de montage peut être démonté sans implication le gestionnaire de système et de service.
Lorsqu'il est utilisé avec After = sur la même unité, le comportement de BindsTo = est encore plus fort. Dans ce cas, l'unité liée strictement doit être en état actif pour que cette unité soit également en état actif. Cela signifie non seulement qu'une unité liée à une autre unité qui entre soudainement en état inactif, mais également une unité liée à une autre unité ignorée en raison d'une vérification de condition ayant échoué (telle que ConditionPathExists =, ConditionPathIsSymbolicLink =,… - voir ci-dessous) sera arrêté, devrait-il être en cours d'exécution. Par conséquent, dans de nombreux cas, il est préférable de combiner BindsTo = avec After =.
Une autre solution pourrait être d’utiliser ExecStartPost option pour redémarrer le service bar.service (s’il est exécuté) lorsque foo.service a (re) démarré:
# foo.service
[Service]
ExecStartPost=/bin/systemctl try-restart bar.service
Restart=on-failure
RestartSec=30s
Les options supplémentaires Restart et RestartSec - garantissent que foo.service sera automatiquement redémarré en cas de blocage, et donc également bar.service.
Une deuxième extension peut être ajoutée à bar.service et s’assurer que bar.service démarre après foo.service:
# bar.service
[Unit]
After=foo.service
[Service]
Restart=on-failure
RestartSec=30s
Cela devrait démarrer les deux services automatiquement en cas de blocage et bar.service sera redémarré au redémarrage de foo.service (suite à une erreur ou au déclenchement manuel).