status=200/CHDIR: systemd hat OpenVPN nie gestartet

Der Dienst schlägt fehl, die Logs nennen einen Spawn und ein Verzeichnis, und der erste Instinkt ist, die VPN-Konfiguration zu prüfen. In dieser Datei wurde noch nichts gelesen. systemd scheiterte beim Vorbereiten des Prozesses, bevor die ausführbare Datei lief, also wurde weder ein Parser noch ein Zertifikat noch ein entfernter Host konsultiert. Den Statuscode als Aussage über systemd statt über OpenVPN zu lesen, macht daraus eine kurze Untersuchung.

Lesen Sie den Statuscode vor der Anwendung

Der numerische Code nach dem Dienstnamen benennt die Stufe, die fehlgeschlagen ist. Ein Verzeichnisfehler wird als CHDIR-Status gemeldet, während eine nicht ausführbare Datei ein völlig anderer Code ist. Beide sehen in einer Zusammenfassungszeile ähnlich aus und haben in ihren Ursachen nichts gemeinsam.

Diese Unterscheidung ist wichtig, weil die Korrekturen in verschiedenen Dateien liegen. Ein CHDIR-Fehler betrifft einen Pfad und die Sicht des Dienstes darauf. Ein Exec-Fehler betrifft die Binärdatei, ihren Interpreter oder einen unabhängigen Mount. Änderungen am VPN-Remote, an der Cipher-Liste oder am Zertifikatspfad können keinen der beiden beheben.

Bestätigen Sie, dass der Fehler beim Start auftritt und nicht nach einem erfolgreichen Lauf. Wenn der Dienst gestern funktionierte und jetzt in derselben Stufe scheitert, hat sich etwas am Verzeichnis, an seinen Berechtigungen oder an der Unit selbst geändert, und diese Änderung ist der Beleg, nach dem Sie suchen.

Fragen Sie die Unit, wo sie sein will

Lesen Sie die effektive Unit statt der Datei, von der Sie annehmen, dass sie installiert ist, denn Drop-ins können das Arbeitsverzeichnis überschreiben, ohne dass Sie je die Haupt-Unit bearbeiten. Die show-Ausgabe beantwortet die Frage direkt:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Für die Upstream-Server-Vorlage ist das Arbeitsverzeichnis das Serverkonfigurationsverzeichnis, und der Instanzname wählt das Profil darin aus. Eine Instanz namens branch erwartet daher ihre eigene Datei im selben Verzeichnis, und ein anderswo abgelegtes Profil erfüllt die Anforderung an das Arbeitsverzeichnis überhaupt nicht.

Vergleichen Sie, was die Unit verlangt, mit dem, was existiert. Ein Pfad, der früher existierte, ein Symlink, der jetzt woanders hinzeigt, oder ein Instanzname, der nicht mehr zu einem Verzeichnis passt, sind alltägliche Änderungen, die genau diesen Fehler erzeugen.

Prüfen Sie den Pfad, wie der Dienst ihn sieht

Ihre Shell und der Dienst teilen nicht dieselbe Dateisystemsicht. Ein konfiguriertes Root-Verzeichnis oder Root-Image ändert, was ein absoluter Pfad innerhalb der Unit bedeutet, und ein auf dem Host offensichtlich vorhandener Pfad kann in diesem Namespace fehlen. Lesen Sie die Einstellungen der Unit, bevor Sie einem manuellen Test vertrauen.

Berechtigungen verschärfen das Problem. Der Dienst läuft als ein bestimmter Benutzer, und dieser Benutzer muss jedes übergeordnete Verzeichnis durchqueren können, um das Ziel zu erreichen, nicht nur das Ziel selbst lesen. Ein Verzeichnis, das für root lesbar und für den Dienstbenutzer nicht durchquerbar ist, erzeugt einen Fehler, der wie ein fehlender Pfad aussieht.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Härtungseinstellungen gehören ebenfalls zu diesem Bild. Eine Unit, die Home-Verzeichnisse verbirgt oder einen Teil des Dateisystems schreibgeschützt macht, tut genau das, wofür sie konfiguriert wurde, und das Arbeitsverzeichnis muss dort liegen, wo die Sandbox es noch freigibt.

Beheben Sie den Eigentümer, dann erwarten Sie einen anderen Fehler

Korrigieren Sie das Layout oder die Unit über den, dem diese Konfiguration gehört. Ein Profil in das erwartete Verzeichnis zu verschieben ist eine legitime Korrektur, wenn das Layout falsch ist, erklärt aber kein Verzeichnis, in das man nicht wechseln kann, also behandeln Sie es nicht als die allgemeine Antwort.

Widerstehen Sie der Abkürzung, Berechtigungen am Konfigurationsbaum zu erweitern oder die Sandbox zu entfernen. Beides lässt das Symptom verschwinden, entfernt aber die Schutzmaßnahmen, die absichtlich dort platziert wurden, und der nächste Fehler wird schwerer zu deuten sein.

Starten Sie die Instanz neu und lesen Sie das nächste Ereignis, statt Erfolg anzunehmen. Der wahrscheinliche nächste Fehler ist, dass OpenVPN seine Konfigurationsdatei nicht öffnen kann, was Fortschritt ist: Das Arbeitsverzeichnis wurde betreten und der Parser läuft jetzt. Folgen Sie von dort dem tatsächlichen Dateimapping der Unit, statt zur Netzwerkfehlersuche zurückzukehren.

Die systemd-Ausführungsreferenz definiert, wie das Arbeitsverzeichnis zusammen mit Root-Verzeichnissen und Sandboxing interpretiert wird. Das Muster, das man sich merken sollte, ist einfach: Jeder Statuscode benennt eine andere Stufe, und nur die eigenen Fehler der Anwendung beschreiben die Anwendung.