SSH-sessie sterft met de VPN: tmux of een jobrunner?

Uw VPN-indicator wordt groen, de route is terug, en het SSH-venster dat u open liet, geeft nooit meer een prompt. Een route herstellen herstelt niet het TCP-gesprek dat er gebruik van maakte, dus alles wat in dat venster is getypt, is weg. Als de echte zorg een editorbuffer of een lange migratie is, is de oplossing om dat werk niet langer aan één verbinding te binden. tmux en een jobrunner lossen verschillende helften van dat probleem op.

Een opnieuw verbonden VPN hervat de socket niet

TCP kent geen begrip van hervatten na een adreswijziging. De SSH-verbinding wordt door beide eindpunten geïdentificeerd, en wanneer de tunnel opnieuw wordt opgebouwd, kan het lokale adres veranderen en is de oude socket dood. De server merkt het uiteindelijk, maar uw terminal merkt het meteen.

Een keepalive aan clientzijde detecteert een dode tegenpartij eerder. Hij brengt de sessie niet terug en kan een commando dat al liep niet herstellen. De keepalive is een detector, geen herstelgereedschap. Hij zegt niets over de vraag of het externe commando het heeft overleefd.

Zet het werk op de externe host

Maak de sessie op de externe host, niet op de laptop. Verbind zoals gewoonlijk, start tmux daar, en voer de editor of migratie daarbinnen uit. Koppel los met het standaardvoorvoegsel en de sessie blijft draaien terwijl de SSH-verbinding verdwijnt. tmux lokaal starten beschermt uw shell tegen een gesloten venster, niet een extern commando tegen een dode tunnel.

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

Zodra de VPN terug is, opent u een nieuwe SSH-verbinding naar dezelfde host en koppelt u opnieuw aan op naam. Het duurzame object is de sessie, niet de verbinding. Geef hem een naam die u een week later nog herkent.

tmux tegenover een jobrunner

tmux houdt een interactief proces in leven zolang de host aan staat. Een jobrunner of servicemanager houdt een niet-interactieve taak in leven, registreert de exitstatus en overleeft het volledig eindigen van de SSH-sessie. Het eerste is voor werk dat u bekijkt; het tweede voor werk dat u plant en later controleert.

Geen van beide overleeft een herstart, tenzij de host is ingesteld om het te herstellen. Een tmux-sessie sterft met de machine, en een tijdelijke taak sterft met de boot, tenzij hij als unit is geregistreerd. Kies op basis van wat het werk moet overleven.

Beide benaderingen hebben ook een logboek nodig dat u na het opnieuw verbinden kunt lezen. Zonder een weet u dat het proces bestaat, maar niet wat het heeft gedaan. Schrijf het logpad naast de sessienaam op.

Bepaal op basis van wat moet overleven

Bepaal op basis van het ergste dat kan gebeuren als het werk halverwege stopt. Een editorsessie verliest niet-opgeslagen buffers, wat vervelend maar herstelbaar is. Een migratie die de helft van zijn wijzigingen vastlegt, is dat niet, en dat pleit voor een runner met een vastgelegd resultaat. Als de taak interactief en lang is, is tmux plus een geschreven logboek meestal genoeg.

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

Wat u ook kiest, controleer het vastgelegde resultaat voordat u iets opnieuw start. Een ontbrekende laatste regel vertelt u wat de laptop zag, niet wat de server vastlegde. Dat onderscheid is de reden om het werk vanaf het begin buiten de verbinding te houden, en het model van loskoppelen en opnieuw aanhaken is daar de kleinste versie van.