PID-Datei vorhanden, kein Tunnel: Lief OpenVPN jemals?

Wenn der Starter OpenVPN nicht startet, weil bereits eine PID-Datei existiert, liegt die natürliche Lesart nahe, dass irgendwo ein Tunnel läuft. Diese Lesart ist oft genug falsch, um sie vor jedem Löschen zu prüfen. Eine Datei in einem Laufzeitverzeichnis ist Buchhaltung, und Buchhaltung überlebt Abstürze, Neustarts und unterbrochene Herunterfahren, die keinen Prozess hinterlassen haben. Zwei Fragen entscheiden den Fall: Gibt es einen lebenden Prozess, und gehört dieser Prozess zu dieser Instanz.

Beginnen Sie beim Dienst, nicht bei der Datei

Die Ablehnung kommt meist von einem Starter und nicht von OpenVPN selbst. Er liest einen Pfad, findet dort etwas und hält an, bevor eine Konfiguration ausgewertet wird. Die erste Frage betrifft daher den Vertrag des Starters, nicht den Tunnel.

Lesen Sie die Unit oder das Skript, das die Meldung ausgegeben hat, und notieren Sie drei Dinge: den geprüften Pfad, den erklärten Diensttyp und ob sie überhaupt für das Schreiben der Datei zuständig ist. Eine moderne Unit kann einfache oder Notify-Überwachung nutzen und eine PID-Datei nie berühren, während ein älteres Init-Skript selbst eine anlegt. Eine Prüfung von einem Modell auf das andere zu kopieren erzeugt genau diese Art Ablehnung. Finden Sie zuerst heraus, welches Modell verwendet wird, bevor Sie irgendetwas deuten.

Erst dann stellt sich die Frage, ob tatsächlich eine Instanz läuft.

Prüfen Sie, ob diese Kennung zu Ihrer Instanz gehört

Eine Zahl in einer Datei beweist, dass eine Zahl geschrieben wurde. Sie beweist nicht, dass ein Prozess mit dieser Kennung jetzt existiert, und schon gar nicht, dass der Prozess Ihrer ist, weil Kennungen nach einem Neustart wiederverwendet werden.

Vergleichen Sie die Startzeit des Prozesses mit dem Zeitstempel der Datei, das ausführbare Programm mit dem Befehl der Unit und die Dienstzugehörigkeit mit dem Namen der Unit. Eine Abweichung bei einem der drei bedeutet, dass Sie Buchhaltung und keinen Tunnel sehen.

Auf einem Host mit Containern oder mehreren Namensräumen kann eine Kennung in einer Ansicht aussagekräftig und in einer anderen abwesend sein. Einen Prozess nicht zu sehen ist ebenfalls kein Beweis, dass er nicht existiert, wenn Ihr Konto ihn nicht einsehen kann. Prüfen Sie aus dem Kontext, den der Starter nutzt, bevor Sie Schlüsse ziehen.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Was der Starter mit der Datei zu tun versprach

PIDFile= sagt dem Dienstmanager, wo er die Kennung des Hauptprozesses lesen soll. Der Manager schreibt diese Datei nicht, entfernt aber eine überlebende nach dem Herunterfahren, und genau deshalb kann ein unterbrochenes Beenden eine Datei hinterlassen.

Diese Aufgabenteilung erklärt zwei Symptome, die als Fehler gemeldet werden. Eine Datei, die nie erscheint, bedeutet, dass der Daemon oder sein Skript sie nicht geschrieben hat, und nicht, dass die Überwachung falsch konfiguriert ist. Eine Datei, die ein Stoppen überlebt, bedeutet, dass der Herunterfahrpfad nie abgeschlossen wurde.

Das erklärt auch, warum aktuelle Empfehlungen raten, die Konvention zu meiden, wenn die Überwachung den Hauptprozess direkt verfolgen kann. Diese Empfehlung ist keine Erlaubnis, den Typ einer gepackten Unit zu ändern, denn das Vordergrund-, Forking- oder Benachrichtigungsverhalten des Daemons muss zu dem passen, was die Unit erklärt. Ändern Sie den Typ, ohne den Daemon zu ändern, und Sie erhalten eine Unit, die einen Fehler meldet, während der Tunnel läuft, oder das Gegenteil. Bringen Sie das Paar zusammen oder lassen Sie beides. Die systemd-Dienstreferenz beschreibt diese Aufteilung der Zuständigkeit.

Sauberes Herunterfahren versus unterbrochenes Beenden

Ein sauberer Stopp bittet den Daemon zu beenden, wartet auf ihn und lässt den Manager seine eigene Buchhaltung aufräumen. Ein unterbrochenes Beenden, ein getöteter Prozess oder ein Neustart mitten im Herunterfahren überspringt Teile dieser Abfolge, und die Datei ist das, was bleibt. Eine nach einem Absturz zu finden sagt Ihnen, dass das Herunterfahren nicht abgeschlossen wurde, nicht dass etwas lauscht.

Vergleichen Sie den Zeitstempel der Datei mit dem letzten Start und mit dem letzten Stopp der Unit.

Prüfen Sie dann die lebenden Belege direkt. Ein an den VPN-Port gebundener Socket und eine Tunnel-Schnittstelle mit Adresse sind der Beweis, dass etwas läuft, auf eine Weise, wie es eine Textdatei in einem Laufzeitverzeichnis nie ist. Fehlen beide, läuft nichts, was die Datei auch behauptet.

Hören Sie auf, die Datei aus Gewohnheit zu löschen

Sie zu löschen ist ein legitimer Wiederherstellungsschritt, sobald Sie festgestellt haben, dass keine Instanz sie besitzt und dass der Starter dieses Verhalten dokumentiert.

Als dauerhafte Gewohnheit vor dem Start untergräbt es die Prüfung, die Sie umgehen. Wenn veraltete Dateien nach jedem sauberen Stopp zurückkehren, sind sich der Schreiber und der Lebenszyklus des Herunterfahrens uneinig, wer den Pfad besitzt, und diese Uneinigkeit ist der Fehler, der es wert ist, behoben zu werden.

Halten Sie sich einen unabhängigen Weg in den Host offen, starten Sie eine Instanz über ihren normalen Manager und lesen Sie das erste Ergebnis. Die nächste Person bekommt eine Unit, die entweder funktioniert oder sich selbst erklärt.