Linux-VPN- und Proxydienste in der richtigen Reihenfolge beenden

Hänger beim Herunterfahren, während ein Proxy läuft, sind selten ein VPN-Fehler, selbst wenn das VPN das Letzte ist, was auf dem Bildschirm zu sehen ist. Anwendungen hinter dem Proxy warten noch auf einen Pfad, der gleich verschwindet, und die Unit, der der Tunnel gehört, wurde noch nicht gebeten, ihn zu schließen. Was wie ein langsamer Dienst aussieht, ist meist ein Reihenfolgeproblem. Die Reihenfolge löst mehr davon als jede Änderung der Zeitüberschreitung.

Arbeiten Sie rückwärts von außen nach innen: zuerst die Verbraucher, dann der Proxy, dann der Tunnel, jeweils gestoppt von der Komponente, die ihn gestartet hat.

Units auflisten, bevor etwas gestoppt wird

Notieren Sie die Anwendungs-Unit, die Proxy-Unit und den VPN-Eigentümer, die an einem normalen Lauf beteiligt sind. Fügen Sie jeden Resolver oder Helfer mit eigenem Abbau hinzu, denn genau die werden um zwei Uhr morgens vergessen. Ohne diese Liste wählt der erste Stoppbefehl, den Sie tippen, ein zufälliges Opfer.

Namen sind schwache Beweise. Ein Benutzerproxy, ein Systemproxy und der Tunnel eines anderen Kontos können denselben Namen tragen und völlig unabhängige Lebenszyklen haben.

Arbeit abschließen, dann den Verbraucher stoppen

Ein geplanter Stopp beginnt bei der Anwendung: Lassen Sie sie ihre Anfragen abschließen oder abbrechen und stoppen Sie dann den Proxy über seine Dienst-Unit. Soll die Anwendung nach dem Verschwinden des Tunnels weiterlaufen, regeln Sie das bewusst, statt sie an eine Route zu hängen, die gleich verschwindet.

Anfragen, die während des Stopps unterwegs waren, gehören in den Datensatz, denn von dort kommt beim nächsten Start der Wiederholungssturm.

ExecStop und ExecStopPost sind verschiedene Werkzeuge

ExecStop= ist der synchrone Stoppvorgang; ExecStopPost= ist Aufräumen, das auch nach einem fehlgeschlagenen Start läuft. Ein Stoppbefehl, der nur ein Signal an einen Prozess sendet und zurückkehrt, lässt systemd weiterlaufen, während der Verbraucher noch ausspült. Alles, was auf jeden Fall geschehen muss, gehört in die Post-Variante, und alles, was den Stopp blockieren muss, in die synchrone. Prüfen Sie die effektive Unit und ihre Drop-ins, statt eine Paketdatei an Ort und Stelle zu bearbeiten.

Ein Abhängigkeitsgraph ordnet Stoppjobs. Er macht aus einem asynchronen Skript kein synchrones und bringt eine entfernte Anwendung nicht dazu, ihre Daten zu sichern.

Den Stopp begrenzen und wissen, was die Grenze kostet

TimeoutStopSec= begrenzt sowohl den Stoppbefehl als auch die eigene Beendigung des Dienstes, und systemd eskaliert zum erzwungenen Abschießen, wenn die Grenze abläuft. Wählen Sie den Wert nach dem tatsächlichen Ausspülverhalten der Anwendung und notieren Sie, was verloren gehen kann, wenn er greift. Eine Zahl, die gewählt wurde, weil die Maschine schneller abschalten soll, ist eine Datenverlust-Einstellung in Verkleidung.

Wenn ein Stopp noch langsam ist, halten Sie die Unit, ihre Kindprozesse, das Journal-Intervall und das Ergebnis der Zeitüberschreitung fest. Jede Zeitüberschreitung zu verkürzen oder zu einem pauschalen Abschießen zu greifen, ist der Weg, auf dem saubere Shutdowns beim nächsten Start zu beschädigtem Zustand werden.

Über den Eigentümer trennen, dann drei Fälle testen

Wenn die Verbraucher unten sind, bitten Sie den Manager, dem der Tunnel gehört, um das Trennen: die systemd-Instanz, die aktive NetworkManager-Verbindung oder den Dienst des Herstellers. Das Abschießen eines unbeteiligten OpenVPN-Prozesses entfernt nicht unbedingt die Sitzung, die die Route geliefert hat, und ein Proxy mit Neustartrichtlinie kann eine Anfrage neu erzeugen, während Sie den Pfad abbauen. Stimmen Sie diese Richtlinie vor dem Beginn mit dem geplanten Stopp ab.

Testen Sie einen normalen Stopp, einen Stopp mit aktiver Anfrage und einen Stopp, bei dem der Tunnel zuerst ausfällt. Eine wiederholbare Abfolge mit Frist schlägt ein schnelles Herunterfahren, das einmal funktioniert.