Einheit -.mount ist maskiert: OpenVPN-Client startet nicht

Eine übrig gebliebene -.mount-Datei in /run/systemd/system maskiert die Root-Mount-Einheit, sodass jede Einheit, die das Dateisystem braucht, scheitert, bevor OpenVPN startet.

Ihr Dienst scheitert, bevor OpenVPN überhaupt läuft, und die Fehlermeldung spricht von einer Mount-Einheit, die Sie nie konfiguriert haben. Das ist der Hinweis: systemd lehnt die gesamte Transaktion ab, weil die Root-Mount-Einheit maskiert ist, und Ihr VPN-Profil wurde noch gar nicht gelesen. Die übliche Ursache ist eine liegen gebliebene Datei im Laufzeitverzeichnis für Units, nicht eine kaputte fstab und nicht ein fehlendes Zertifikat. Gehen Sie zuerst der Datei nach, denn sie ist die billigste Erklärung, die Sie ausschließen können.

Der Fehler nennt den Root-Mount, nicht Ihr Profil

systemd erzeugt die Root-Mount-Einheit selbst aus den Mount-Informationen des Kernels und nennt sie -.mount, weil ein Bindestrich für den Wurzelpfad steht. Diese Einheit existiert normalerweise nur im Speicher, und dahinter steht keine Datei. Wenn der Fehler sagt, sie sei maskiert, hat etwas eine Unit-Datei dorthin gelegt, wo systemd sie lädt, und diese Datei auf /dev/null zeigen lassen. Die Maskierung ist ein echter Zustand und kein Tippfehler in der Meldung.

Die Instanz-Einheit scheitert, weil ihr Job-Graph über die Reihenfolge und über ihre eigenen Mount-Anforderungen den Root-Mount erreicht. Die Transaktion wird abgelehnt, bevor das OpenVPN-Binary ausgeführt wird, also kann nichts in der Konfiguration des Clients die Ursache sein. Deshalb hat ein Wechsel von Profilen, Zertifikaten oder Zugangsdaten auf genau diesen Fehler keine Wirkung.

Sehen Sie im Laufzeitverzeichnis nach, bevor Sie OpenVPN debuggen

Suchen Sie im Laufzeitverzeichnis für Units nach einer Datei mit genau diesem Namen und fragen Sie dann systemd, was er für diese Einheit hält. Beide Antworten sind schnell, und zusammen trennen sie eine liegen gebliebene Datei von einem echten Mount-Problem.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Auf einer normalen Maschine gibt es keine solche Datei, und die Liste der maskierten Units enthält den Root-Mount nicht. Wenn der erste Befehl einen Symlink auf /dev/null ausgibt, ist die Diagnose gesichert. Dasselbe Verzeichnis kann eine tmp.mount-Maskierung enthalten, die dasselbe Werkzeug angelegt hat, und das erzeugt dieselbe Fehlerklasse unter einem anderen Namen. Sehen Sie sich das ganze Verzeichnis an und nicht nur den Namen aus der Fehlermeldung.

ls -la /run/systemd/system/*.mount

Ist das Verzeichnis sauber und die Einheit trotzdem maskiert, liegt die Maskierung woanders im Suchpfad, und systemctl cat -.mount zeigt, welche Datei geladen wird.

Datei löschen, neu laden und erneut starten

Die Laufzeitdatei zu entfernen und den Manager neu zu laden reicht aus, und es berührt nichts, was aus einem Paket stammt. Laden Sie vor dem Start neu, denn systemd behält den geladenen Zustand der Unit, bis es das Verzeichnis erneut liest.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Lesen Sie danach das Journal des Dienstes selbst, statt anzunehmen, die Reparatur habe gewirkt. Ein sauberer Start beweist nur, dass systemd die Unit akzeptiert hat; der Client kann weiterhin an einem fehlenden Profil, einem nicht erreichbaren Peer oder einem Zertifikat sterben, das nicht validiert. Das sind gewöhnliche OpenVPN-Probleme, die hinter der maskierten Unit verborgen waren. Es hält fest, welches Profil geladen wurde und ob der Tunnel tatsächlich stand. Wenn die Unit startet und der Tunnel nicht, sind Sie bei einem anderen Problem angelangt, und das ist Fortschritt.

journalctl -u [email protected] -b --no-pager

Weil /run ein temporäres Dateisystem ist, räumt ein Neustart die Datei ebenfalls weg. Das macht einen Neustart zu einem nützlichen Test: Funktioniert der Dienst nach einem Neustart und scheitert nach dem nächsten Deployment wieder, wird die Datei ins Image eingebacken.

Verhindern Sie, dass sie aus dem Image zurückkommt

Eine Container- oder VM-Vorlage, die beim Build Mount-Units maskiert, trägt diese Maskierung in jeden Klon. Was als Nächstes das Dateisystem braucht, bricht, und die Meldung gibt dem Mount die Schuld statt dem Image, aus dem er stammt. Eine Reparatur in einer laufenden Instanz versteckt das Problem bis zur nächsten erzeugten Instanz.

Durchsuchen Sie den Build-Kontext nach dem Dateinamen und nach dem Befehl, der ihn erzeugt, entfernen Sie dann die Maskierung aus der Vorlage und bauen Sie neu. Wird die Maskierung beim Build wirklich gebraucht, entfernen Sie sie in derselben Schicht, die den Build abschließt, damit das ausgelieferte Image sauber startet. Prüfen Sie an einem frischen Klon und nicht auf der Maschine, die Sie von Hand repariert haben. Das ist der einzige Test, der beweist, dass sich das Image geändert hat.

Das Symptom, das Sie sich merken sollten, ist die Diskrepanz zwischen der Fehlermeldung und dem, was Sie konfiguriert haben. Wenn systemd sich über einen Mount beschwert, während Sie einen VPN-Client starten, lesen Sie zuerst den Unit-Namen in der Meldung und dann den Dienstnamen.

Ähnliche Artikel