Etwas startet immer wieder eine OpenVPN-Unit: Quelle finden

Eine OpenVPN-Instanz kommt beim Start unter einem Namen hoch, den Sie nicht kennen, und das Stoppen funktioniert bis zum nächsten Neustart. Dieses Muster bedeutet, dass Sie den Prozess entfernt, aber nicht die Aktivierung beseitigt haben. Beide sind verschiedene Objekte, und nur eines davon ist in einer Statusanzeige sichtbar. Die Aktivierung zu finden erfordert vier schreibgeschützte Befehle und eine Entscheidung.

Zuerst die genaue Unit benennen

Arbeiten Sie mit dem Unit-Namen aus dem Journal statt mit einem Profildateinamen. Die Instanz kann openvpn@, openvpn-client@, openvpn-server@ oder etwas distributionsspezifisches heißen, und ein geratener Name führt Sie zur falschen Vorlage. Die Statusausgabe nennt die Unit, die tatsächlich lief, und nur dieser Name zählt hier. Kopieren Sie ihn exakt, einschließlich eines etwaigen Suffixes.

Die folgenden Befehle beschreiben diese Unit, ohne etwas zu ändern. systemctl show meldet den Fragmentpfad, den Quellpfad, den Zustand der Unit-Datei, etwaige Drop-ins und was sie ausgelöst hat. list-dependencies --reverse zeigt, welche geladenen Units auf sie verweisen. Beide sind schreibgeschützt, führen Sie sie also aus, bevor Sie eine Theorie bilden.

Ersetzen Sie den beobachteten Namen überall. Ein kopierter Beispielname ist der häufigste Weg, den falschen Dienst zu untersuchen, und er liefert selbstsichere Antworten über eine Unit, die nie lief.

Die Vorlage lesen, um den Dateinamen zu erfahren

Eine Instanz-Unit ist die Erweiterung einer Vorlage, und die Vorlage entscheidet, welche Konfigurationsdatei gelesen wird. Eine Befehlszeile, die in einem instanzbezogenen Platzhalter endet, wird zum Instanznamen plus Suffix aufgelöst. Ist das Suffix .conf und heißt die Instanz old, lautet die Datei old.conf. Nennen Sie die Instanz old.conf, verlangt dieselbe Vorlage old.conf.conf.

Dieses Detail erklärt eine Klasse von Duplikaten. Jemand fügt eine zweite Instanz unter dem falschen Namen hinzu, die erste läuft weiter, und der Host hat am Ende zwei Tunnel und ein verwirrendes Protokoll.

Lesen Sie die wirksame Vorlage statt der Datei, die Sie zu bearbeiten glauben. Ein Drop-in kann die Befehlszeile ersetzen, und beim Start läuft die Ersetzung.

Nachvollziehen, wie sie in die Boot-Transaktion gelangt

Drei Wege sind üblich: eine Wants-Verknüpfung von einem Target, eine Anforderung einer anderen Unit oder eine erzeugte Unit aus einem Paketgenerator. Die Auflistung der Rückwärtsabhängigkeiten deckt die ersten beiden als geladene Graph-Einträge ab. Einen Timer, einen Hook oder eine externe Anfrage deckt sie nicht ab, weshalb die Auflistung ein Beleg und kein vollständiges Audit ist.

Erzeugte Ausgabe unter /run/systemd/generator ist ein Produkt, keine Quelle. Änderungen daran überleben nur bis zur nächsten Generierung, weshalb eine dort angewandte Korrektur erfolgreich wirkt und dann zurückfällt.

Prüfen Sie die dokumentierte Eingabe des Pakets, bevor Sie annehmen, woher der Generator liest. Ein undokumentierter Verzeichnis-Scan ist der übliche Grund, warum eine Unit ohne Aktivierungsverknüpfung erscheint.

Die Aktivierung entfernen, nicht nur den Prozess

Ist die Instanz direkt aktiviert und wirklich veraltet, stoppt systemctl disable --now sie und entfernt die Boot-Verknüpfung in einem Schritt. Prüfen Sie zuerst, ob dieser Tunnel nicht Ihr einziger administrativer Weg zum Host ist. Der Befehl ist ein Lebenszyklus-Beispiel, keine Aufforderung, jedes VPN auf der Maschine zu stoppen. Führen Sie die Prüfung vor dem Befehl aus, nicht danach.

Die beiden Hälften sind trennbar und werden oft verwechselt. Deaktivieren stoppt keinen laufenden Dienst, und Stoppen entfernt keine Aktivierung, daher erklärt ein Teilbefehl ein Problem, das beim Start zurückkehrt.

Eine deaktivierte Unit kann trotzdem von einer anderen Unit oder durch eine ausdrückliche Anfrage gestartet werden. Wenn ein Generator die Aktivierung besitzt, korrigieren Sie dessen Eingabe, statt seine Ausgabe zu deaktivieren. Maskieren blockiert mehr Wege, kann aber Abhängigkeiten brechen, es ersetzt also kein Verständnis.

Mit einem Neustart prüfen, nicht mit einer Statusanzeige

Laden Sie systemd neu, wenn sich Unit-Definitionen oder Generator-Eingaben geändert haben, und prüfen Sie dann den resultierenden Zustand. Ein Daemon-Reload schiebt kein neues Profil in einen laufenden Tunnel, die beiden Prüfungen sind also getrennt. Planen Sie einen Neustart ein und bestätigen Sie, dass die Instanz fehlt und der beabsichtigte Tunnel weiterhin funktioniert.

Behalten Sie das alte Profil, bis sein Eigentümer geklärt ist, und ziehen Sie es dann über den vorgesehenen Prozess zurück. Erfolg ist eine fehlende Unit und ein funktionierender Zugangsweg, nicht eine fehlgeschlagene Unit, die auf einer Anzeige fehlt.