Eine fehlgeschlagene Voraussetzung blockiert den Dienst · Linux Fix Lab

Symptome und Geltungsbereich

Es erscheint keine neue Startmeldung der Anwendung.
Der Startauftrag endet mit Ergebnis dependency.

Betroffene Umgebung

systemd-Abhängigkeiten mit Requires, Wants, After und RequiresMountsFor.

Erkennbare Meldungen (synthetische Beispiele)

systemd[1]: example.service: Job example.service/start failed with result 'dependency'.

Das belegt keinen Absturz des Anwendungsprogramms.

Mögliche Ursachen

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

Ein benötigter Mount oder Daemon kann vor der Startfreigabe dieses Dienstes gescheitert sein.
Eine optionale Ressource kann als erforderlich deklariert sein; After ordnet Units, startet sie aber nicht.

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 Zieldienst; es werden nur Abhängigkeiten gelesen.

systemctl show example.service -p Requires -p Wants -p After -p RequiresMountsFor

Ergebnis einordnen: Requires und Wants ziehen Units in einen Auftrag; After ergänzt die Reihenfolge. Ordne den Fehler einer konkreten Voraussetzung zu.

Prüfschritt 2

Listet fehlgeschlagene System-Units; nutze bei Benutzerdiensten den passenden Benutzer-Manager.

systemctl --failed --no-pager

Ergebnis einordnen: Ein fehlgeschlagener Mount in der Kette ist relevant; unbeteiligte fehlerhafte Units belegen keine Ursache.

Prüfschritt 3

Ersetze prerequisite.service durch die ermittelte Abhängigkeit; Journalzugriff kann eingeschränkt sein.

journalctl -b -u prerequisite.service --no-pager -n 80

Ergebnis einordnen: Behebe ihren ersten Fehler vor dem erneuten Zielstart. Eine gesunde Voraussetzung spricht für die Prüfung von Graph und Reihenfolge.

Nächste Schritte nach Befund

Die tatsächliche Voraussetzung wiederherstellen

Wenn der Dienst den Mount oder Daemon benötigt, behebe diese Unit und prüfe zuerst ihre Bereitschaft. Prüfe bei Datenverzeichnissen das erwartete Dateisystem statt nur die Existenz des Pfads.

Vorsicht: Ein Start auf einem leeren Mountpunkt kann einen zweiten Datenbestand im Root-Dateisystem erzeugen. Bewahre die Abhängigkeitslogs auf.

Wiederherstellung / Rücknahme: Stelle Änderungen an der Voraussetzung zurück und lasse den abhängigen Dienst gestoppt, bis seine Ressource gültig ist.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Eine optionale Abhängigkeit passend modellieren

Wenn die Dokumentation den Betrieb ohne die Komponente erlaubt, ersetze unnötiges Requires durch ein passendes Wants und behalte erforderliche Reihenfolgen bei. Prüfe das Verhalten ohne diese Komponente.

Vorsicht: Das verändert die Fehlerweitergabe. Schwäche benötigte Datenbank-, Geheimnis- oder Speicherabhängigkeiten nicht nur für einen aktiven Zustand.

Wiederherstellung / Rücknahme: Stelle die ursprüngliche Beziehung zurück, lade Units neu und starte die vollständige Voraussetzungskette.