Persistente Services sind Dienste, die unabhängig von interaktiven Sitzungen, temporären Prozessen oder manuellen Startbefehlen dauerhaft laufen sollen. Sie überleben Reboots, Session-Wechsel, Logout-Ereignisse und erfüllen im Kern dieselbe Rolle wie klassische Hintergrunddienste. In modernen Linux-Umgebungen basiert ihre Implementierung auf systemd – entweder im globalen Systemkontext oder im rootless User-Scope. Persistenz meint nicht nur Verfügbarkeit, sondern auch deterministisches Verhalten, kontrollierbare Restarts und klare Zustandsmodelle.
Ein persistenter Service ist mehr als ein Skript in
rc.local oder ein Cronjob. Persistenz umfasst:
Man spricht hier von „Service-Lifecycles“, nicht von „Prozessstarts“. Persistenz ist ein formaler Vertrag: systemd übernimmt die Verantwortung, den Dienst dauerhaft in einem definierten Zustand zu halten.
Ein strukturelles Bild:
Systemweite persistente Services sind das klassische Modell. Eine Unit wird aktiviert und systemd garantiert, dass der Dienst läuft:
sudo systemctl enable myservice.service
sudo systemctl start myservice.serviceDiese Dienste:
Sie sind die natürliche Wahl für Infrastrukturprozesse, Datenbanken, APIs oder Komponenten, die mehrere Benutzer versorgen sollen.
Typische Struktur:
[Unit]
Description=Backend API
After=network-online.target
[Service]
ExecStart=/usr/local/bin/backend-api
Restart=always
[Install]
WantedBy=multi-user.targetDiese Unit ist ein vollständiger persistenter Dienst.
Der User-Scope ist die moderne Alternative – besonders relevant für rootless Podman, lokale Entwicklungsserver, persönliche Build-Agenten oder isolierte Komponenten. Persistenz im User-Kontext wird über systemd und Linger erreicht:
loginctl enable-linger <user>
systemctl --user enable devserver.serviceDas erzeugt einen persistenten Dienst, der:
Dieses Modell trennt Verantwortung: Nutzer administrieren eigene Services, die stabil über Reboots hinweg bestehen, ohne das System zu gefährden.
Ein entscheidendes Detail: Persistente rootless Services starten bereits während des Systemboots – auch wenn sich der User nie einloggt.
Persistente Dienste benötigen robuste Restart-Semantik. Eine Unit kann mit fein abgestimmten Restart-Verhalten betrieben werden:
Restart=always
RestartSec=3oder granularer:
Restart=on-failure
StartLimitIntervalSec=30
StartLimitBurst=5Diese Einstellungen verhindern, dass ein flackernder Prozess das System überschwemmt, und garantieren trotzdem einen konsistenten Betriebszustand.
Eine Prozessverletzung – etwa ein Exit-Code ≠ 0 – löst systemd-gesteuertes Recovery aus. Persistente Services sind damit mechanisch „selbstheilend“.
Persistenz ist selten isoliert. Persistente Dienste sind meist Teil von Service-Ketten:
systemd verwaltet diese Ketten über Abhängigkeiten:
Requires=postgresql.service
After=postgresql.serviceEin persistenter Dienst wird so nicht nur dauerhaft betrieben, sondern korrekt orchestriert. Services, die ohne ihre Abhängigkeiten starten, führen häufig zu Race Conditions. Persistenz ist ohne Ordnung wertlos.
Diagramm:
Ein persistenter Dienst speichert in der Regel Daten, Konfigurationen oder Laufzeitinformationen. systemd kennt dafür klare Orte:
/var/lib/<service> für dauerhaften State/var/run/<service> (bzw. /run) für
temporären State$HOME/.local/state/<service> für rootless
DienstePersistente Services erfordern, dass der zugrundeliegende State stabil ist. Beispiele:
~/.local/share/containers und überleben Reboots./var/lib.Persistenz im Dienst bedeutet immer Persistenz in der Datenhaltung.
Podman führt zu einer neuen Kategorie persistenter Services: Container-Units und Pod-Units, die genau dieselben Mechanismen nutzen wie klassische systemd-Dienste.
Container als persistente Services:
podman generate systemd --new --files --name webappPod als persistenter Verbund:
podman generate systemd --new --files --name app-podDer Container wird zum Dienst, das Image wird zur Codebasis, systemd wird zum Supervisor. Persistenz entsteht aus der Kombination aus Container-Laufzeit und systemd-Überwachung – ohne Daemon, ohne Root.
Persistente Services müssen nicht dauerhaft laufen. Auch Timer können persistent sein, z. B.:
systemctl --user enable backup.timerTimer sind die moderne Alternative zu Cron, mit klaren Abhängigkeiten, Logging und systemd-Kontrolle.
Beispiel Timer + Service:
backup.service
backup.timerDiese Kombination ist persistent, wiederholbar und exakt kontrolliert.
Persistente Services bilden das Rückgrat eines zuverlässigen Systems – lokal, serverseitig oder containerisiert. Die Mechanik basiert auf systemd, entweder systemweit oder im rootless Bereich. Persistenz ist keine Nebenerscheinung, sondern eine architektonische Eigenschaft, die definiert, wie Dienste über Zeiträume hinweg stabil und vorhersehbar operieren.