SSH-session dør med VPN: tmux eller en jobkører?

Din VPN-indikator bliver grøn, ruten er tilbage, og det SSH-vindue, du lod stå åbent, giver aldrig en prompt igen. At genskabe en rute genskaber ikke den TCP-samtale, der brugte den, så alt, hvad der blev skrevet i det vindue, er væk. Hvis den egentlige bekymring er en editor-buffer eller en lang migrering, er løsningen at holde op med at binde det arbejde til én forbindelse. tmux og en jobkører løser forskellige halvdele af det problem.

En genoprettet VPN genoptager ikke socketten

TCP har ingen forestilling om at genoptage efter en adresseændring. SSH-forbindelsen identificeres ved begge endepunkter, og når tunnelen genopbygges, kan den lokale adresse ændre sig, og den gamle socket er død. Serveren bemærker det til sidst, men din terminal bemærker det med det samme.

En klient-keepalive opdager en død modpart tidligere. Det bringer ikke sessionen tilbage, og det kan ikke genskabe en kommando, der allerede kørte. Keepaliven er en detektor, ikke et gendannelsesværktøj. Det siger intet om, hvorvidt den fjernkommando overlevede.

Læg arbejdet på fjernværten

Opret sessionen på fjernværten, ikke på laptop'en. Forbind som sædvanligt, start tmux der, og kør editoren eller migreringen inde i den. Kobl fra med standardpræfikset, og sessionen kører videre, mens SSH-forbindelsen forsvinder. At starte tmux lokalt beskytter din shell mod et lukket vindue, ikke en fjernkommando mod en død tunnel.

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

Når VPN'en er tilbage, åbn en ny SSH-forbindelse til samme vært, og genoptag ved navn. Sessionen er det holdbare objekt, ikke forbindelsen. Giv den et navn, du stadig genkender en uge senere.

tmux kontra en jobkører

tmux holder en interaktiv proces i live, mens værten kører. En jobkører eller service manager holder et ikke-interaktivt job i live, registrerer dets exitstatus og overlever, at SSH-sessionen slutter helt. Det første er til arbejde, du overvåger; det andet er til arbejde, du planlægger og undersøger senere.

Ingen af dem overlever en genstart, medmindre værten er konfigureret til at genskabe det. En tmux-session dør med maskinen, og et forbigående job dør med opstarten, medmindre det blev registreret som en unit. Vælg efter, hvad arbejdet skal overleve.

Begge tilgange kræver også en log, du kan læse efter genoprettelsen. Uden en ved du, at processen findes, men ikke hvad den har gjort. Skriv logstien ned ved siden af sessionsnavnet.

Beslut efter, hvad der skal overleve

Beslut efter det værste, der kan ske, hvis arbejdet stopper halvvejs. En editorsession mister ugemte buffere, hvilket er irriterende, men gendanneligt. En migrering, der committer halvdelen af sine ændringer, er ikke, og det taler for en kører med et registreret resultat. Hvis jobbet er interaktivt og langt, er tmux plus en skrevet log normalt nok.

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

Uanset hvad du vælger, så undersøg det registrerede resultat, før du kører noget igen. En manglende sidste linje fortæller dig, hvad laptoppen så, ikke hvad serveren committede. Den forskel er grunden til at holde arbejdet væk fra forbindelsen fra begyndelsen, og model for frakobling og genoptagelse er den mindste udgave af det.