SSH-Sitzung stirbt mit dem VPN: tmux oder ein Job-Runner?

Ihre VPN-Anzeige wird grün, die Route ist zurück, und das SSH-Fenster, das Sie offen gelassen haben, gibt nie wieder eine Eingabeaufforderung zurück. Eine Route wiederherzustellen stellt nicht die TCP-Verbindung wieder her, die sie benutzt hat, also ist alles, was in dieses Fenster getippt wurde, verloren. Wenn die eigentliche Sorge ein Editor-Puffer oder eine lange Migration ist, besteht die Lösung darin, diese Arbeit nicht mehr an eine Verbindung zu binden. tmux und ein Job-Runner lösen unterschiedliche Hälften dieses Problems.

Ein neu verbundenes VPN setzt den Socket nicht fort

TCP kennt kein Fortsetzen nach einem Adresswechsel. Die SSH-Verbindung wird durch beide Endpunkte bestimmt, und wenn der Tunnel neu aufgebaut wird, kann sich die lokale Adresse ändern und der alte Socket ist tot. Der Server merkt es irgendwann, Ihr Terminal merkt es sofort.

Ein Client-Keepalive erkennt einen toten Gegenüber früher. Er bringt die Sitzung nicht zurück und kann einen bereits laufenden Befehl nicht wiederherstellen. Der Keepalive ist ein Detektor, kein Wiederherstellungswerkzeug. Er sagt nichts darüber aus, ob der entfernte Befehl überlebt hat.

Legen Sie die Arbeit auf den entfernten Host

Erstellen Sie die Sitzung auf dem entfernten Host, nicht auf dem Laptop. Verbinden Sie sich wie gewohnt, starten Sie dort tmux und führen Sie den Editor oder die Migration darin aus. Lösen Sie sich mit dem Standardpräfix und die Sitzung läuft weiter, während die SSH-Verbindung verschwindet. tmux lokal zu starten schützt Ihre Shell vor einem geschlossenen Fenster, nicht einen entfernten Befehl vor einem toten Tunnel.

ssh [email protected]
tmux new-session -s office-work

Sobald das VPN zurück ist, öffnen Sie eine neue SSH-Verbindung zum selben Host und hängen sich per Namen wieder an. Das dauerhafte Objekt ist die Sitzung, nicht die Verbindung. Geben Sie ihr einen Namen, den Sie auch eine Woche später noch erkennen.

tmux gegen einen Job-Runner

tmux hält einen interaktiven Prozess am Leben, solange der Host läuft. Ein Job-Runner oder Dienstmanager hält einen nicht interaktiven Job am Leben, zeichnet dessen Exit-Status auf und überlebt das vollständige Ende der SSH-Sitzung. Das erste ist für Arbeit, die Sie beobachten; das zweite für Arbeit, die Sie planen und später prüfen.

Keines von beiden überlebt einen Neustart, es sei denn, der Host ist darauf eingerichtet, es wiederherzustellen. Eine tmux-Sitzung stirbt mit der Maschine, und ein flüchtiger Job stirbt mit dem Bootvorgang, es sei denn, er wurde als Unit registriert. Wählen Sie danach, was die Arbeit überleben muss.

Beide Ansätze brauchen außerdem ein Protokoll, das Sie nach dem Wiederverbinden lesen können. Ohne eines wissen Sie, dass der Prozess existiert, aber nicht, was er getan hat. Notieren Sie den Protokollpfad neben dem Sitzungsnamen.

Entscheiden Sie nach dem, was überleben muss

Entscheiden Sie nach dem Schlimmsten, das passieren kann, wenn die Arbeit auf halbem Weg stoppt. Eine Editor-Sitzung verliert ungespeicherte Puffer, was ärgerlich, aber wiederherstellbar ist. Eine Migration, die die Hälfte ihrer Änderungen festschreibt, ist es nicht, und das spricht für einen Runner mit aufgezeichnetem Ergebnis. Wenn der Job interaktiv und lang ist, reicht tmux plus ein geschriebenes Protokoll meist aus.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Was auch immer Sie wählen, prüfen Sie das aufgezeichnete Ergebnis, bevor Sie etwas erneut starten. Eine fehlende letzte Zeile sagt Ihnen, was der Laptop gesehen hat, nicht was der Server festgeschrieben hat. Genau dieser Unterschied ist der Grund, die Arbeit von vornherein von der Verbindung zu lösen, und das Modell des Trennens und Wiederverbindens ist die kleinste Variante davon.