SSH-økt dør med VPN: tmux eller en jobbkjøring?
En gjenopprettet tunnel vekker ikke den gamle SSH-socketen. Bestem om arbeidet trenger en terminaløkt du kobler til igjen, eller en jobb med et registrert resultat.
VPN-indikatoren blir grønn, ruten er tilbake, og SSH-vinduet du lot stå åpent gir aldri en ledetekst igjen. Å gjenopprette en rute gjenoppretter ikke TCP-samtalen som brukte den, så alt som ble skrevet i det vinduet, er borte. Hvis den egentlige bekymringen er en editor-buffer eller en lang migrering, er løsningen å slutte å binde det arbeidet til én forbindelse. tmux og en jobbkjøring løser hver sin halvdel av det problemet.
En gjenopprettet VPN gjenopptar ikke socketen
TCP har ingen forestilling om å gjenoppta etter en adresseendring. SSH-forbindelsen identifiseres av begge endepunktene, og når tunnelen bygges opp igjen, kan den lokale adressen endre seg og den gamle socketen er død. Tjeneren merker det til slutt, men terminalen din merker det umiddelbart.
En keepalive på klientsiden oppdager en død motpart tidligere. Den henter ikke tilbake økten, og den kan ikke gjenopprette en kommando som allerede kjørte. Keepaliven er en detektor, ikke et gjenopprettingsverktøy. Den sier ingenting om hvorvidt fjernkommandoen overlevde.
Legg arbeidet på fjernverten
Opprett økten på fjernverten, ikke på laptopen. Koble til som vanlig, start tmux der, og kjør editoren eller migreringen inne i den. Koble fra med standardprefikset, og økten fortsetter å kjøre mens SSH-forbindelsen forsvinner. Å starte tmux lokalt beskytter skallet ditt mot et lukket vindu, ikke en fjernkommando mot en død tunnel.
ssh [email protected]
tmux new-session -s office-workNår VPN-en er tilbake, åpne en ny SSH-forbindelse til samme vert og koble til igjen ved navn. Det varige objektet er økten, ikke forbindelsen. Gi den et navn du fortsatt kjenner igjen en uke senere.
tmux kontra en jobbkjøring
tmux holder en interaktiv prosess i live så lenge verten kjører. En jobbkjøring eller tjenesteadministrator holder en ikke-interaktiv jobb i live, registrerer avslutningsstatusen og overlever at SSH-økten avsluttes helt. Det første er for arbeid du følger med på; det andre for arbeid du planlegger og undersøker senere.
Ingen av dem overlever en omstart med mindre verten er satt opp til å gjenopprette det. En tmux-økt dør med maskinen, og en forbigående jobb dør med oppstarten med mindre den ble registrert som en enhet. Velg etter hva arbeidet må overleve.
Begge tilnærmingene trenger også en logg du kan lese etter å ha koblet til igjen. Uten en vet du at prosessen finnes, men ikke hva den har gjort. Skriv ned loggbanen ved siden av øktnavnet.
Bestem etter hva som må overleve
Bestem etter det verste som kan skje hvis arbeidet stopper halvveis. En editorøkt mister ulagrede buffere, noe som er irriterende men gjenopprettelig. En migrering som committer halvparten av endringene sine, er ikke det, og det taler for en kjøring med et registrert resultat. Hvis jobben er interaktiv og lang, er tmux pluss en skrevet logg vanligvis nok.
systemd-run --user --unit=migrate-customers --collect ./migrate.shUansett hva du velger, undersøk det registrerte resultatet før du kjører noe på nytt. En manglende siste linje forteller deg hva laptopen så, ikke hva tjeneren committet. Den forskjellen er grunnen til å holde arbeidet utenfor forbindelsen fra begynnelsen, og modell for frakobling og gjenoppkobling er den minste utgaven av det.