72 Restart-Strategien

Restart-Strategien sind ein fundamentaler Bestandteil robuster Linux-Dienste. Sie definieren, wie systemd auf Fehler, Abbrüche, Zeitüberschreitungen oder externe Signale reagiert. In produktionsnahen Systemen ist die Restart-Policy genauso wichtig wie das eigentliche Startkommando. Sie entscheidet darüber, ob ein Dienst zuverlässig verfügbar bleibt, ob er im Crashfall sauber regeneriert wird oder ob er sich bei hartnäckigen Fehlern selbst „totläuft“. Gerade beim Betrieb von Containern, Microservices und Backend-Prozessen ist die Wahl der richtigen Restart-Strategie ein zentrales Architekturdetail.

72.1 Restart als Teil des Service-Lifecycle

Ein Dienst existiert nicht nur in den Phasen „Start“ und „Stop“. Er durchläuft Zustände:

systemd modelliert diese Zustände explizit und macht sie über Restart-Strategien kontrollierbar. Ein Restart ist keine Notmaßnahme, sondern ein geplantes Verhalten.

Ein abstrahierter Ablauf:

72.2 Die wichtigsten Restart-Policies

systemd kennt mehrere grundlegende Restart-Modi. Jeder Modus besitzt eine klare Semantik:

72.2.1 always

Der Dienst wird immer neu gestartet, unabhängig vom Exit-Code.

Restart=always

Einsatzgebiet: persistent laufende Services wie Webserver, Datenbanken, Container, Worker.

72.2.2 on-failure

Restartet nur, wenn der Prozess abnormal beendet wurde – Exit-Code ≠ 0, Signal, Crash.

Restart=on-failure

Einsatzgebiet: Dienste, die im Erfolgsfall regulär beenden dürfen, aber bei Fehlern erneut laufen sollen.

72.2.3 on-abnormal

Nur bei abnormalen Beendigungen: Crash, OOM-Killer, Signale.

Restart=on-abnormal

72.2.4 on-abort

Restart, wenn das Programm mit einem Signal terminiert wird, das nicht abgefangen wurde.

Restart=on-abort

72.2.5 on-success

Wird selten genutzt, aber manchmal praktisch: Dienst wird neu gestartet, wenn er erfolgreich beendet wurde.

Restart=on-success

72.2.6 no

Kein automatischer Restart.

Restart=no

Am besten geeignet für One-Shot-Jobs, einmalige Konfigurationstasks, Migrationsskripte.

72.3 RestartSec – die Ruhephase zwischen Versuchen

Restart-Prozesse benötigen Delays. Ohne sie kommt es zu „Restart-Stürmen“, bei denen systemd einen flackernden Service dutzende Male pro Sekunde startet. Das ist ineffizient und kann Logfiles, Kernelspace oder Netzwerkressourcen überlasten.

RestartSec=5

Systemd wartet 5 Sekunden vor jedem Restart-Versuch. Für containerisierte Anwendungen ist dieser Wert besonders wichtig, weil Images initialisieren müssen, Netzwerke hochkommen oder Datenbanken bereit sein müssen.

72.4 StartLimitBurst und StartLimitIntervalSec

Diese Parameter verhindern Eskalationsschleifen.

StartLimitIntervalSec=30
StartLimitBurst=5

Bedeutung:

Ergebnis:

systemctl status myservice
→ Start request repeated too quickly.

Diese Mechanik schützt das System und erleichtert Diagnose: Wenn ein Dienst dauerhaft crasht, fällt er nicht still in eine Endlosschleife.

72.5 Unterschiede bei Rootless und System-Diensten

Restart-Strategien funktionieren im User-Scope identisch wie im globalen Systemkontext. Ein wesentlicher Unterschied:

Das bedeutet, dass ein fehlerhafter rootless Container nicht das gesamte System belastet, sondern nur die Ressourcen seines Besitzers.

Für rootless Container, die Podman über systemd betreiben, empfiehlt sich meist:

Restart=always
RestartSec=2

Damit erhält man robuste, langfristig stabile containerisierte Services.

72.6 Restarts und Abhängigkeiten

Restart-Policies leben nicht isoliert. Sie interagieren mit dem Dependency-Modell von systemd.

Ein Beispiel:

Requires=postgresql.service
After=postgresql.service

Wenn PostgreSQL während des Betriebs neu startet, beeinflusst das unter Umständen auch abhängige Services. Wenn ein Backend z. B. durch die DB-Down-Phase crasht, sorgt Restart=always dafür, dass es nach dem DB-Recovery automatisch wieder hochkommt.

Das Zusammenspiel lässt sich grafisch verdeutlichen:

Persistente Systeme bestehen aus Ketten robuster Einzelkomponenten, deren Restart-Verhalten bewusst entworfen ist.

72.7 Restart-Strategien in Container-Kontexten

Für Podman gilt: systemd ist der Supervisor, nicht Podman selbst. Container-Units enthalten klare Restart-Kommandos:

ExecStop=/usr/bin/podman stop -t 10 backend
ExecStart=/usr/bin/podman run ...
Restart=always

Podman kümmert sich um den Container, systemd um dessen Lebenszyklus. Fällt der Containerprozess aus, sieht systemd das als normalen Prozess-Exit – und startet ihn gemäß Policy neu.

In Pod-Units:

ExecStart=/usr/bin/podman pod start mypod
ExecStop=/usr/bin/podman pod stop -t 10 mypod
Restart=on-failure

Hier greift die Restart-Strategie für den gesamten Pod, nicht für die einzelnen Container. Restarting ist also hierarchisch:

72.8 Restart und Exits: Der Unterschied zwischen 0, 1 und Signalen

Ein präziser Blick auf Exit-Codes ist notwendig:

Restart=on-failure reagiert nur auf „Fehler“, nicht auf reguläre Exits. Wer möchte, dass ein Worker endless läuft, wählt besser:

Restart=always

Für kurzlebige Batch-Prozesse dagegen ist sinnvoll:

Type=oneshot
RemainAfterExit=yes
Restart=no

72.9 Sonderfall: Crash Loops sichtbar machen

Dienste, die in Crashloops geraten, erzeugen Muster im Journal. Ein praktisches Diagnosefragment:

journalctl -u myservice.service -n 50

systemd markiert Crash-Zyklen sichtbar:

Service has entered a failed state.
Start request repeated too quickly.

Crashloops entstehen fast immer durch:

Professionelle Setups legen daher bewusst moderate Restart-Zeiten fest.

Restart-Strategien sind damit ein präzises Steuerinstrument für robuste Dienste. Sie verbinden die Prozesslaufzeit mit definierter Betriebskontrolle – und bilden den zentralen Baustein für ausfallsichere, nachvollziehbar gesteuerte Service-Lifecycles.