La sessione SSH muore con la VPN: tmux o un esecutore di attività?

L'indicatore della VPN diventa verde, la rotta è tornata, e la finestra SSH che avete lasciato aperta non restituisce mai più il prompt. Ripristinare una rotta non ripristina la conversazione TCP che la usava, quindi tutto ciò che è stato digitato in quella finestra è perso. Se la vera preoccupazione è un buffer dell'editor o una migrazione lunga, la soluzione è smettere di legare quel lavoro a una sola connessione. tmux e un esecutore di attività risolvono metà diverse di quel problema.

Una VPN riconnessa non riprende il socket

TCP non ha alcuna nozione di ripresa dopo un cambio di indirizzo. La connessione SSH è identificata da entrambi gli estremi, e quando il tunnel viene ricostruito l'indirizzo locale può cambiare e il vecchio socket è morto. Il server se ne accorge alla fine, ma il vostro terminale se ne accorge subito.

Un keepalive lato client rileva un peer morto prima. Non riporta indietro la sessione e non può recuperare un comando che era già in esecuzione. Il keepalive è un rilevatore, non uno strumento di recupero. Non dice nulla sulla sopravvivenza del comando remoto.

Mettete il lavoro sull'host remoto

Create la sessione sull'host remoto, non sul portatile. Collegatevi come al solito, avviate tmux lì ed eseguite l'editor o la migrazione al suo interno. Staccatevi con il prefisso predefinito e la sessione continua a girare mentre la connessione SSH sparisce. Avviare tmux in locale protegge la vostra shell da una finestra chiusa, non un comando remoto da un tunnel morto.

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

Quando la VPN torna, aprite una nuova connessione SSH verso lo stesso host e riagganciatevi per nome. L'oggetto durevole è la sessione, non la connessione. Datele un nome che riconoscerete ancora una settimana dopo.

tmux contro un esecutore di attività

tmux mantiene vivo un processo interattivo finché l'host resta acceso. Un esecutore di attività o un gestore di servizi mantiene viva un'attività non interattiva, ne registra lo stato di uscita e sopravvive alla fine completa della sessione SSH. Il primo serve al lavoro che osservate; il secondo al lavoro che pianificate e ispezionate più tardi.

Nessuno dei due sopravvive a un riavvio, a meno che l'host non sia configurato per ripristinarlo. Una sessione tmux muore con la macchina, e un'attività temporanea muore con l'avvio, a meno che non sia stata registrata come unità. Scegliete in base a ciò che il lavoro deve sopravvivere.

Entrambi gli approcci hanno bisogno anche di un registro che possiate leggere dopo la riconnessione. Senza di esso sapete che il processo esiste, ma non cosa ha fatto. Annotate il percorso del registro accanto al nome della sessione.

Decidete in base a ciò che deve sopravvivere

Decidete in base alla cosa peggiore che può succedere se il lavoro si ferma a metà. Una sessione di editor perde i buffer non salvati, il che è fastidioso ma recuperabile. Una migrazione che conferma metà delle sue modifiche non lo è, e questo depone a favore di un esecutore con un esito registrato. Se l'attività è interattiva e lunga, tmux più un registro scritto di solito basta.

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

Qualunque cosa scegliate, ispezionate l'esito registrato prima di rieseguire qualsiasi cosa. Una riga finale mancante vi dice cosa ha visto il portatile, non cosa ha confermato il server. Questa distinzione è la ragione per tenere il lavoro fuori dalla connessione fin dall'inizio, e il modello di distacco e riaggancio ne è la versione più piccola.