Dennis HilkLinux Fix LabEN

Dienste und systemd

WorkingDirectory verhindert den Dienststart

Eine Unit kann vor dem Programmstart mit 200/CHDIR scheitern. Prüfe fehlende Mounts, Durchsuchungsrechte und das Verzeichnis innerhalb ihres Root.

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

  • Der Dienst meldet status=200/CHDIR.
  • Das erwartete Verzeichnis erscheint erst nach einem Mount- oder Deployment-Schritt.

Betroffene Umgebung

systemd-Units mit WorkingDirectory, optionalem RootDirectory oder eigenen Anwendungs-Mounts.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: example.service: Main process exited, code=exited, status=200/CHDIR

Der Fehler liegt vor dem Anwendungsstart; prüfe Pfadsichtbarkeit und Zugriff.

Mögliche Ursachen

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

  • WorkingDirectory kann auf ein entferntes Verzeichnis oder den falschen Pfad im Dienst-Root verweisen.
  • Nicht verfügbarer Speicher oder verweigerter Verzeichniszugriff kann chdir vor dem Start 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; die Abfrage liest wirksame Einstellungen.

systemctl show example.service -p WorkingDirectory -p RootDirectory -p RequiresMountsFor

Ergebnis einordnen: WorkingDirectory ergänzt passende Mount-Abhängigkeiten, erstellt aber kein Verzeichnis. Vergleiche den Wert mit RootDirectory.

Prüfschritt 2

Ersetze den Pfad durch das konfigurierte Host-Verzeichnis; es werden keine Dateien verändert.

namei -l /srv/example/current

Ergebnis einordnen: Ein fehlendes Symlink-Ziel oder unzugänglicher Elternpfad erklärt den Fehler. Sichtbarkeit auf dem Host beweist keine Sichtbarkeit im Dienst-Root.

Nächste Schritte nach Befund

Verzeichnis an das Deployment anpassen

Wenn das Deployment umgezogen ist, setze WorkingDirectory auf den tatsächlichen Pfad im Dienst-Root. Braucht die Anwendung kein festes Arbeitsverzeichnis, ersetze relative Daten- und Konfigurationspfade gezielt.

Vorsicht: Ohne diese Vorgabe können andere relative Dateien gelesen werden. Bewahre früheren Deployment-Symlink und Unit auf.

Wiederherstellung / Rücknahme: Stelle WorkingDirectory und Symlink zurück, lade die Unit neu und starte sie bei verfügbarem Pfad.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Das vorgesehene Verzeichnis bereitstellen

Wenn der Pfad Dienstdaten enthält, stelle ihn mit StateDirectory oder der Distributionskonfiguration und passendem Eigentümer bereit. Liegen die Daten auf einem eigenen Mount, behebe dessen Fehler.

Vorsicht: Ein leeres Ersatzverzeichnis kann einen zweiten Datenbestand erzeugen. Prüfe vor dem Start die erwartete Mount-Quelle.

Wiederherstellung / Rücknahme: Nimm die Bereitstellung zurück, sichere neue Daten getrennt und verbinde den ursprünglichen Mount vor dem 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.