SSH-sessionen dör med VPN: tmux eller en jobbkörare?

Din VPN-indikator blir grön, rutten är tillbaka, och SSH-fönstret du lämnade öppet ger aldrig en prompt igen. Att återställa en rutt återställer inte det TCP-samtal som använde den, så allt som skrevs i det fönstret är borta. Om den egentliga oron är en editorbuffert eller en lång migrering är lösningen att sluta binda arbetet till en enda anslutning. tmux och en jobbkörare löser olika halvor av det problemet.

En återansluten VPN återupptar inte socketen

TCP har ingen föreställning om att återuppta efter en adressändring. SSH-anslutningen identifieras av båda ändpunkterna, och när tunneln byggs upp igen kan den lokala adressen ändras och den gamla socketen är död. Servern märker det till slut, men din terminal märker det direkt.

En keepalive på klientsidan upptäcker en död motpart tidigare. Den tar inte tillbaka sessionen och kan inte återställa ett kommando som redan kördes. Keepaliven är en detektor, inte ett återställningsverktyg. Den säger ingenting om huruvida fjärrkommandot överlevde.

Lägg arbetet på fjärrvärden

Skapa sessionen på fjärrvärden, inte på laptopen. Anslut som vanligt, starta tmux där och kör editorn eller migreringen inuti den. Koppla loss med standardprefixet och sessionen fortsätter köra medan SSH-anslutningen försvinner. Att starta tmux lokalt skyddar ditt skal från ett stängt fönster, inte ett fjärrkommando från en död tunnel.

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

När VPN:en är tillbaka, öppna en ny SSH-anslutning till samma värd och återanslut vid namn. Det varaktiga objektet är sessionen, inte anslutningen. Ge den ett namn du fortfarande känner igen en vecka senare.

tmux kontra en jobbkörare

tmux håller en interaktiv process vid liv så länge värden körs. En jobbkörare eller tjänstehanterare håller ett icke-interaktivt jobb vid liv, registrerar dess slutstatus och överlever att SSH-sessionen avslutas helt. Det första är för arbete du följer; det andra för arbete du schemalägger och inspekterar senare.

Ingen av dem överlever en omstart om inte värden är konfigurerad att återställa det. En tmux-session dör med maskinen, och ett tillfälligt jobb dör med uppstarten om det inte registrerades som en enhet. Välj efter vad arbetet måste överleva.

Båda metoderna behöver också en logg som du kan läsa efter återanslutningen. Utan en vet du att processen finns, men inte vad den har gjort. Skriv ner loggsökvägen bredvid sessionsnamnet.

Bestäm efter vad som måste överleva

Bestäm efter det värsta som kan hända om arbetet stannar halvvägs. En editorsession förlorar osparade buffertar, vilket är irriterande men återställbart. En migrering som checkar in hälften av sina ändringar är inte det, och det talar för en körare med ett registrerat resultat. Om jobbet är interaktivt och långt räcker tmux plus en skriven logg oftast.

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

Vad du än väljer, granska det registrerade resultatet innan du kör något igen. En saknad sista rad säger vad laptopen såg, inte vad servern checkade in. Den skillnaden är anledningen att hålla arbetet utanför anslutningen från början, och modell för frånkoppling och återanslutning är den minsta versionen av det.