Dienste und systemd

Absturzschleife erreicht das systemd-Startlimit

Wiederholte Neustarts enden mit start-limit-hit. Finde den ersten Anwendungsfehler vor Änderungen an Neustartabständen oder dem Zurücksetzen des Zählers.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Der Neustartzähler steigt vor dem Fehler schnell.
  • Ein weiterer Start wird mit start-limit-hit verweigert.

Betroffene Umgebung

systemd-Dienste mit Restart und StartLimitIntervalSec/StartLimitBurst.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: example.service: Start request repeated too quickly.

Finde den ersten fehlgeschlagenen Versuch; das Limit ist nicht dessen Ursache.

systemd[1]: example.service: Failed with result 'start-limit-hit'.

Eine konfigurierte Regel hat einen weiteren Start verweigert.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Ein Konfigurationsfehler oder eine fehlende Ressource kann jeden Versuch sofort beenden.
  • Kurzes RestartSec kann aus einem vorübergehenden Fehler eine Wiederholungsschleife bis zum Startlimit machen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Ersetze example.service; das Lesen setzt die Zähler nicht zurück.

systemctl show example.service -p Result -p NRestarts -p Restart -p RestartUSec -p StartLimitIntervalUSec -p StartLimitBurst

Ergebnis einordnen: Result zeigt die Begrenzung, nicht den ursprünglichen Absturz. Prüfe, ob der Neustartabstand eine Erholung der Voraussetzung erlaubt.

Prüfschritt 2

Lies das Dienstjournal; Zugriff kann Administratorrechte oder die Journal-Gruppe erfordern.

journalctl -b -u example.service -o short-monotonic --no-pager -n 200

Ergebnis einordnen: Gehe zum ersten Fehler vor den Neustarts zurück. Die letzte Startlimit-Meldung beschreibt meist eine Folge.

Nächste Schritte nach Befund

Ersten Fehler beheben und danach starten

Wenn der erste Abbruch einen Konfigurations- oder Ressourcenfehler nennt, behebe ihn zuerst. Setze danach nur den Fehlerzustand dieser Unit zurück und prüfe einen einzelnen Start mit Administratorrechten.

Vorsicht: reset-failed löscht relevante Startlimit-Zähler. Wiederholtes Zurücksetzen kann eine ungelöste Absturzschleife verdecken; bewahre das Journal auf.

Wiederherstellung / Rücknahme: Stelle verschlechternde Konfigurationsänderungen zurück. Ein zurückgesetzter Zähler lässt sich nicht rekonstruieren; vergleiche die gespeicherten Logs.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Gezielten Neustartabstand festlegen

Wenn Wiederholungen zum dokumentierten Fehlerfall passen, erhöhe RestartSec dieses Dienstes und behalte ein endliches Startlimit. Ordne erwartete Beendigungen anhand der dokumentierten Exit-Status-Regel ein.

Vorsicht: Ein größerer Abstand verlängert Ausfälle. Global ausgeschaltete Grenzen können CPU und Logs durch einen defekten Dienst überlasten.

Wiederherstellung / Rücknahme: Stelle frühere Neustart- und Exit-Status-Werte zurück, lade den Manager neu und beobachte einen kontrollierten Neustart.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.