Warum eine VPN-Unit vor dem Netzwerk startet und dann stirbt

Starten Sie die Maschine, melden Sie sich an und stellen Sie fest, dass der Tunnel hochkam und wenige Sekunden später starb. Das Profil war in Ordnung, das Zertifikat war in Ordnung, und die einzige verbleibende Spur ist das Journal von diesem Boot. Was üblicherweise passiert ist, ist ein Wettlauf: Die Unit startete, bevor die Maschine eine Adresse hatte, und die Reihenfolge, die sie deklarierte, bedeutete nicht, wonach sie aussieht. Alles Folgende dreht sich darum, diesen Wettlauf aus Belegen zu beweisen und ihn sauber zu schließen.

Das Ziel ist ein Treffpunkt, kein Verwalter

network-online.target hat keine Ahnung, was ein Netzwerk ist. Es ist ein Koordinationspunkt, der den Dienst sammelt, der den Start verzögern soll, bis die Verbindung nutzbar ist, und er delegiert die Definition an den Netzwerkmanager, dem die Maschine gehört. Auf den meisten Desktops und Servern bedeutet das einen Warte-Dienst, den NetworkManager oder systemd-networkd mitliefert. Aktivieren Sie keinen davon, hat das Ziel nichts, worauf es warten kann, also ist es in dem Moment fertig, in dem etwas es hereinzieht, was lange vor der DHCP-Antwort sein kann. Die Reihenfolgezeile in Ihrer Unit war ehrlich und trotzdem nutzlos.

Die erste Frage ist also nicht, was Ihre Unit deklariert. Sondern ob auf dieser Maschine tatsächlich etwas das Warten übernimmt.

Lesen Sie den letzten Boot statt der Unit-Datei

Unit-Dateien beschreiben die Absicht, und das Journal beschreibt, was passiert ist. Fragen Sie nur diesen Boot ab, mit monotonen Zeitstempeln, damit jede Meldung auf einer Uhr sitzt. Suchen Sie dann zwei Zeilen: den Moment, in dem die Tunnel-Unit zu starten begann, und den Moment, in dem die Adresse erschien oder der Warte-Dienst fertig war. Ordnen Sie diese beiden Zahlen, und der Wettlauf ist entweder bestätigt oder ausgeschlossen.

Die Abhängigkeitsansicht bestätigt es. Enthält eine kritische Kette für die Tunnel-Unit keinen Warte-Dienst, hat nichts auf diesem Pfad den Start verzögert, und das Ziel hat die Arbeit nicht geleistet, die Sie angenommen haben. Zwei Ansichten, eine Schlussfolgerung.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Ergänzen Sie das Warten, dann den Wiederholungsversuch

Verwenden Sie ein Drop-in, statt eine paketierte Unit zu bearbeiten, damit ein Paketupdate die Änderung nicht stillschweigend verwirft. Zwei Direktiven zählen: Die Unit muss nach dem Ziel geordnet sein, und sie muss das Ziel in dieselbe Transaktion ziehen. Ordnung allein ruft das Ziel nicht herbei; der Wunsch danach tut es.

Die paketierte Unit des OpenVPN-Clients trägt beides bereits. Handgeschriebene Units tragen meist eines oder keines, was es wert ist zu prüfen, bevor Sie etwas hinzufügen.

[Service]
Restart=on-failure
RestartSec=15

Warum ein festes Sleep eine Falle ist

Ein Sleep in ExecStartPre fühlt sich wie ein Reihenfolge-Fix an und verhält sich wie eine Verzögerung mit zusätzlichen Schritten. Es bremst jeden Boot, auch die gesunden, und es verliert trotzdem, wenn die Verbindung länger dauert als die Zahl, die Sie gewählt haben.

Schlimmer noch, es verbirgt, ob der Warte-Dienst funktioniert, sodass der nächste Fehler als brandneues Problem erscheint statt als dasselbe mit anderem Timing. Eine kurze Neustartverzögerung ist das bessere Instrument: Sie kostet bei einem gesunden Boot nichts und verwandelt einen verlorenen Wettlauf in einen weiteren Versuch. Halten Sie das Intervall bescheiden und lassen Sie die Unit erfolgreich sein. Startet sie ewig neu, ist das Profil kaputt, und kein Wiederholen ändert das, also lesen Sie das Log, statt das Intervall zu erhöhen.

Wenn die Reihenfolge stimmt und Namen trotzdem scheitern

Eine aktive Unit mit einer Tunnelroute bedeutet, dass die Reihenfolge ihre Arbeit getan hat und der verbleibende Fehler eine Ebene höher sitzt. Die übliche Form ist eine Resolver-Einstellung, die das Up-Skript des Tunnels anwendet, bevor die Verbindung oder der Resolver bereit war, sie zu halten. Vergleichen Sie den Resolver-Zustand während des Fehlers mit dem Zustand nach einem Neustart der Tunnel-Unit.

Behebt der Neustart die Auflösung, haben Sie einen Startreihenfolge-Defekt und keinen falschen DNS-Server, und die beiden brauchen unterschiedliche Korrekturen. Beweisen Sie dann das Ganze mit einem Kaltstart statt einem Dienstneustart, denn ein Neustart läuft gegen ein Netzwerk, das schon oben ist, und verdeckt genau den Defekt, den Sie jagen. Wiederholen Sie es mit absichtlich langsamer Verbindung, und behandeln Sie eine Unit, die nur bei schnellem Netzwerk funktioniert, als weiterhin kaputt.