Ein Dienst steht auf failed und startet nicht. Die Ursache steht fast immer im Journal — man muss nur den richtigen Befehl kennen, um sie zu lesen.
Aufwand:
ca. 20 Min.
Voraussetzung:
sudo-Rechte, Terminal
Das Symptom
Ein Dienst — Webserver, Datenbank, ein eigenes Programm — läuft nicht. systemctl status zeigt ihn in Rot mit dem Wort failed, und jeder Startversuch endet sofort
wieder im selben Zustand. Manchmal versucht systemd es ein paarmal automatisch und
gibt dann ganz auf.
Die „Layer 8“-Wahrheit
Die Fehlermeldung failed sagt nur, dass etwas schiefging, nicht was. Das ist
der Grund, warum so viele an dieser Stelle raten statt zu lesen. Dabei protokolliert
systemd jeden Startversuch minutiös — die eigentliche Fehlerzeile liegt im Journal
und ist mit dem richtigen Filter in Sekunden sichtbar.
Fast immer steht dort etwas Konkretes: ein belegter Port, ein Tippfehler in der
Konfigurationsdatei, ein fehlendes Verzeichnis oder falsche Rechte. Zwei Stolperfallen
gibt es dabei: Nach dem Ändern einer Unit-Datei muss systemd sie mit daemon-reload
neu einlesen, und nach zu vielen Fehlversuchen sperrt es weitere Starts, bis man
den Zustand mit reset-failed zurücksetzt. Wer das Journal liest, statt es zu
ignorieren, löst diese Klasse von Fehlern fast immer allein.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Status ansehen
Der erste Blick gilt dem Status. Er zeigt, ob der Dienst wirklich fehlgeschlagen ist, und meist schon die letzten Zeilen der Fehlerausgabe:
systemctl status dienstname
2.
Das Journal des Dienstes lesen
Die eigentliche Ursache steht im Journal. Mit dem Filter auf genau diese Unit sieht man die vollständige Fehlerausgabe des letzten Startversuchs — hier steht praktisch immer, woran es lag:
journalctl -u dienstname -e --no-pager
3.
Die häufigsten Ursachen prüfen
Typisch sind: ein Tippfehler in der Konfiguration, ein bereits belegter Port, ein fehlender Pfad oder falsche Dateirechte. Die Journal-Zeile nennt fast immer eine davon konkret beim Namen.
4.
Nach Änderungen die Unit neu einlesen
Wurde die Dienstdatei bearbeitet, muss systemd sie erst neu einlesen, sonst startet weiter die alte Version:
sudo systemctl daemon-reload
5.
Den Fehlerzähler zurücksetzen und neu starten
Hat der Dienst zu oft hintereinander versagt, blockiert systemd weitere Startversuche. Nach dem Beheben der Ursache den Zustand zurücksetzen und neu starten:
?Der Dienst startet nicht. Wo steht der eigentliche Grund?
Im Journal, nicht in der Statusausgabe. journalctl -u dienstname -n 50 zeigt die letzten Meldungen des Dienstes und benennt in aller Regel die Ursache direkt – falscher Pfad, fehlende Rechte, belegter Port. Die Statusanzeige sagt nur, dass es schiefging, nicht warum.
?Ich habe die Unit-Datei geändert, es ändert sich nichts. Warum?
Weil systemd seine Konfiguration im Speicher hält. Nach jeder Änderung an einer Unit-Datei muss systemctl daemon-reload ausgeführt werden – sonst startet weiterhin die alte Fassung, und man sucht den Fehler in einer Datei, die gar nicht verwendet wird.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.