Dennis HilkLinux Fix LabEN

Dienste und systemd

Ein Dienst verpasst seinen Userspace-Watchdog

Ein Dienst wird wegen fehlender WATCHDOG=1-Meldungen abgebrochen. Prüfe Meldungsunterstützung, Absender und Arbeitsstaus vor dem Ändern des Zeitlimits.

Redaktionelle Quellenprüfung: Mit den Hinweisen beginnenAnleitung teilen
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

  • Das Dienstjournal meldet Watchdog timeout.
  • Auf den Abbruch kann eine Erholung nach Restart-Regel folgen.

Betroffene Umgebung

systemd-Watchdog mit WatchdogSec pro Dienst; getrennt von Kernel-Lockup-Erkennung und Hardware-Watchdogs.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: example.service: Watchdog timeout (limit 30s)!

Ein Dienst-Heartbeat fehlt; dies ist keine Kernel-Watchdog-Diagnose.

Mögliche Ursachen

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

  • Watchdog-Unterstützung kann fehlen oder Meldungen stammen von einem durch NotifyAccess ausgeschlossenen Prozess.
  • Eine blockierte Ereignisschleife, Scheduling-Verzögerung oder ein I/O-Stau kann vorhandene Heartbeats verhindern.

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 den Dienstnamen; liest den Watchdog-Zustand unverändert.

systemctl show example.service -p WatchdogUSec -p NotifyAccess -p WatchdogTimestampMonotonic -p Result

Ergebnis einordnen: Ein Intervall größer null verlangt regelmäßige Unterstützung der Anwendung. Result=watchdog unterscheidet sich von einem normalen Exit-Code-Fehler.

Prüfschritt 2

Nutze die betroffene Unit; eingeschränkte Journale brauchen berechtigten Lesezugriff.

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

Ergebnis einordnen: Vergleiche Ablauf und letzten Fortschritt. Wiederholte Staus an einer Stelle rechtfertigen deren Untersuchung, bestimmen aber nicht die blockierende Ressource.

Nächste Schritte nach Befund

Den Watchdog-Meldeweg korrigieren

Wenn Unterstützung vorhanden ist, konfiguriere dokumentierten Meldemodus und zugelassenen Absender. Fehlt Unterstützung, entferne eine lokal ergänzte WatchdogSec-Vorgabe dieses Dienstes.

Vorsicht: Ohne Vorgabe entfällt die Hängererkennung. Ein vom Anwendungszustand unabhängiger Heartbeat kann Blockaden verbergen.

Wiederherstellung / Rücknahme: Stelle Meldemodus sowie frühere WatchdogSec-/NotifyAccess-Werte wieder her und beobachte normalen Betrieb.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Gemessenen Stau oder Zeitlimitfehler beheben

Wenn Fortschritt ausbleibt, untersuche blockierte Arbeit und behebe Ressourcen- oder Parallelitätsprobleme. Überschreitet eine dokumentierte gesunde Operation das Intervall, wähle ein passendes endliches Budget nur für diesen Dienst.

Vorsicht: Ein größeres Intervall verzögert die Erholung von echten Hängern. Sichere Zeitfolge und Core-Dump-Hinweise vor Neustartserien.

Wiederherstellung / Rücknahme: Stelle das frühere Intervall oder die Anwendung zurück und vergleiche Fortschritt und Heartbeats bei gleicher Last.

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.