La sessió SSH mor amb la VPN: tmux o un executor de tasques?

L'indicador de la VPN es posa verd, la ruta torna, i la finestra SSH que vau deixar oberta no torna mai a mostrar l'indicatiu d'ordres. Restaurar una ruta no restaura la conversa TCP que la feia servir, així que tot el que es va escriure en aquella finestra s'ha perdut. Si la preocupació real és un búfer de l'editor o una migració llarga, la solució és deixar de lligar aquesta feina a una sola connexió. tmux i un executor de tasques resolen meitats diferents d'aquest problema.

Una VPN reconectada no reprèn el sòcol

TCP no té cap noció de reprendre després d'un canvi d'adreça. La connexió SSH s'identifica per tots dos extrems, i quan el túnel es reconstrueix, l'adreça local pot canviar i el vell sòcol és mort. El servidor se n'adona al final, però el vostre terminal se n'adona de seguida.

Un keepalive del client detecta un company mort abans. No torna la sessió, i no pot recuperar una ordre que ja s'estava executant. El keepalive és un detector, no una eina de recuperació. No diu res sobre si l'ordre remota ha sobreviscut.

Poseu la feina a l'amfitrió remot

Creeu la sessió a l'amfitrió remot, no a l'ordinador portàtil. Connecteu-vos com sempre, inicieu tmux allà i executeu l'editor o la migració a dins. Desenganxeu-vos amb el prefix per defecte i la sessió continua funcionant mentre la connexió SSH desapareix. Iniciar tmux localment protegeix la vostra shell d'una finestra tancada, no una ordre remota d'un túnel mort.

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

Quan la VPN torni, obriu una connexió SSH nova al mateix amfitrió i torneu-vos a enganxar pel nom. L'objecte durador és la sessió, no la connexió. Poseu-li un nom que encara reconegueu al cap d'una setmana.

tmux enfront d'un executor de tasques

tmux manté viu un procés interactiu mentre l'amfitrió està engegat. Un executor de tasques o un gestor de serveis manté viva una tasca no interactiva, n'enregistra l'estat de sortida i sobreviu que la sessió SSH s'acabi del tot. El primer és per a feina que mireu; el segon, per a feina que programeu i inspeccioneu més tard.

Cap dels dos sobreviu a un reinici tret que l'amfitrió estigui configurat per restaurar-lo. Una sessió de tmux mor amb la màquina, i una tasca transitòria mor amb l'arrencada tret que s'hagi registrat com a unitat. Trieu segons què ha de sobreviure la feina.

Tots dos enfocaments també necessiten un registre que pugueu llegir després de reconnectar. Sense un, sabeu que el procés existeix, però no què ha fet. Anoteu el camí del registre al costat del nom de la sessió.

Decidiu pel que ha de sobreviure

Decidiu per la pitjor cosa que pot passar si la feina s'atura a mig camí. Una sessió d'editor perd els búfers no desats, cosa que empipa però és recuperable. Una migració que comet la meitat dels seus canvis no ho és, i això afavoreix un executor amb un resultat enregistrat. Si la tasca és interactiva i llarga, tmux més un registre escrit sol ser suficient.

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

Triï el que triï, reviseu el resultat enregistrat abans de tornar a executar res. Una última línia que falta us diu què va veure el portàtil, no què va cometre el servidor. Aquesta distinció és la raó de mantenir la feina fora de la connexió des del principi, i el model de desenganxar i tornar a enganxar n'és la versió més petita.