it-swarm.com.de

So starten Sie einen Dienst neu, wenn der abhängige Dienst neu gestartet wird

Ein Dienst (z. B. bar.service) ist abhängig von einem anderen Dienst (z. B. foo.service) wie unten

servicedatei der Bar:

[Unit]
After=foo.service
Requires=foo.service
...

Wenn foo.service neu gestartet wird (entweder manuell oder aufgrund eines Fehlers), wie kann bar.service ebenfalls automatisch neu gestartet werden?

16
iobelix

Sie können PartOf verwenden.

[Unit]
After=foo.service
Requires=foo.service
PartOf=foo.service

Auf der systemd.unit-Manpage:

PartOf =

Konfiguriert Abhängigkeiten ähnlich wie Requires =, ist jedoch auf das Stoppen und Neustarten von Einheiten beschränkt. Wenn systemd die hier aufgelisteten Einheiten stoppt oder neu startet, wird die Aktion an diese Einheit weitergegeben. Beachten Sie, dass dies eine unidirektionale Abhängigkeit ist - Änderungen an dieser Einheit wirken sich nicht auf die aufgelisteten Einheiten aus.

27
Kevin M Granger

Ich denke, die benötigte Option ist BindsTo, sie behandelt auch das Fehlverhalten.

[Unit]
Requires=postgresql.service
After=postgresql.service
BindsTo=postgresql.service

BindsTo =

Konfiguriert Anforderungsabhängigkeiten, deren Stil dem von Requires = sehr ähnlich ist. Dieser Abhängigkeitstyp ist jedoch stärker: Neben der Auswirkung von Requires = wird angegeben, dass die Einheit auch angehalten wird, wenn die Einheit, an die sie gebunden ist, gestoppt wird. Dies bedeutet, dass eine an eine andere Einheit gebundene Einheit, die plötzlich in den inaktiven Zustand übergeht, ebenfalls gestoppt wird. Einheiten können unerwartet aus verschiedenen Gründen unerwartet in den inaktiven Zustand übergehen: Der Hauptprozess einer Serviceeinheit wird möglicherweise nach eigener Wahl beendet, das Sicherungsgerät einer Geräteeinheit wird möglicherweise nicht angeschlossen, oder der Einhängepunkt einer Bereitstellungseinheit kann ohne Beteiligung von unmountiert werden der System- und Service-Manager.

Bei Verwendung in Verbindung mit After = in derselben Unit ist das Verhalten von BindsTo = noch stärker. In diesem Fall muss die Einheit, an die strikt gebunden ist, aktiv sein, damit auch diese Einheit aktiv ist. Dies bedeutet nicht nur, dass eine Einheit an eine andere Einheit gebunden ist, die plötzlich in den inaktiven Status wechselt, sondern auch eine Einheit, die an eine andere Einheit gebunden ist, die aufgrund einer fehlgeschlagenen Zustandsüberprüfung übersprungen wird (z. B. ConditionPathExists =, ConditionPathIsSymbolicLink =,… - siehe unten) gestoppt, sollte es laufen. Daher ist es in vielen Fällen am besten, BindsTo = mit After = zu kombinieren.

1
ego2dot0

Eine andere Lösung wäre die Verwendung der Option ExecStartPost, um den bar.service neu zu starten (falls er ausgeführt wird), wenn foo.service (neu) gestartet wurde:

# foo.service
[Service]
ExecStartPost=/bin/systemctl try-restart bar.service
Restart=on-failure
RestartSec=30s

Die zusätzlichen Optionen Restart und RestartSec stellen sicher, dass foo.service bei einem Absturz automatisch neu gestartet wird und somit auch bar.service.

Eine zweite Erweiterung kann hinzugefügt werden, um bar.service hinzuzufügen und sicherzustellen, dass bar.service nach foo.service gestartet wird:

# bar.service
[Unit]
After=foo.service

[Service]
Restart=on-failure
RestartSec=30s

Dies sollte im Falle eines Absturzes beide Dienste automatisch starten und bar.service wird neu gestartet, wenn foo.service neu gestartet wird (aufgrund eines Fehlers oder manuell ausgelöst).

0
panticz.de