Dennis HilkLinux Fix LabEN

Dienste und systemd

Ein notify-Dienst wird nicht startbereit

Der Prozess läuft, doch Type=notify bleibt bis zum Zeitlimit im Startzustand. Prüfe Bereitschaftsmeldungen, Absender und blockierte Initialisierung.

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

  • Die Unit bleibt während des Startintervalls auf activating.
  • systemd beendet sie am Zeitlimit, obwohl ihr Prozess existiert.

Betroffene Umgebung

systemd-Dienste mit Type=notify oder notify-reload; die Anwendung muss Bereitschaftsmeldungen unterstützen.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: example.service: start operation timed out. Terminating.

Auch andere Diensttypen erzeugen dies; prüfe Type=notify vor Änderungen am Bereitschaftsprotokoll.

Mögliche Ursachen

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

  • READY=1 kann fehlen oder von einem durch NotifyAccess ausgeschlossenen Prozess stammen.
  • Eine Migration, blockierte Abfrage oder fehlende Abhängigkeit kann den tatsächlichen Startabschluss 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 Unit-Namen; es wird kein Zustandswechsel angefordert.

systemctl show example.service -p Type -p NotifyAccess -p TimeoutStartUSec -p MainPID -p SubState

Ergebnis einordnen: Type=notify wartet auf Bereitschaft. NotifyAccess=main akzeptiert den Hauptprozess; Wrapper und Kindprozesse können die Zuordnung verändern.

Prüfschritt 2

Lies das Journal der betroffenen Unit; administrative Leserechte können nötig sein.

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

Ergebnis einordnen: Vergleiche Fortschritt und Zeitlimit. Eine antwortende Anwendung ohne Meldung unterscheidet sich von einer blockierten Migration.

Nächste Schritte nach Befund

Den unterstützten Diensttyp verwenden

Wenn die Anwendung notify nicht unterstützt, nutze ihren dokumentierten Diensttyp, etwa exec für ein Vordergrundprogramm, sofern unterstützt. Bei notify korrigiere Wrapper oder Absenderzuordnung.

Vorsicht: Ohne notify entfällt die Bereitschaftsgarantie für abhängige Units. Melde Bereitschaft nie vor Abschluss der Initialisierung.

Wiederherstellung / Rücknahme: Stelle Type und NotifyAccess wieder her, lade die Definition neu und starte bei zulässiger Unterbrechung.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Gemessene Initialisierung berücksichtigen

Wenn der Start voranschreitet, aber länger als das endliche Limit dauert, wähle ein passendes TimeoutStartSec oder unterstützte EXTEND_TIMEOUT_USEC-Meldungen. Behebe blockierte Voraussetzungen zuerst.

Vorsicht: Mehr Startzeit kann Boot und Deployments verzögern. Sie behebt keinen dauerhaften Hänger.

Wiederherstellung / Rücknahme: Stelle früheres Zeitlimit und Anwendungskonfiguration wieder her; vergleiche einen weiteren Start mit der gespeicherten Zeitfolge.

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.