SSH-kunsido mortas kun la VPN: tmux aŭ task-plenumilo?

Via VPN-indikilo verdiĝas, la itinero revenas, kaj la SSH-fenestro, kiun vi lasis malferma, neniam plu redonas prompton. Restarigi itineron ne restarigas la TCP-interparoladon, kiu uzis ĝin, do ĉio tajpita en tiun fenestron perdiĝis. Se la vera zorgo estas redaktila bufro aŭ longa migrado, la solvo estas ĉesi ligi tiun laboron al unu konekto. tmux kaj task-plenumilo solvas malsamajn duonojn de tiu problemo.

Religita VPN ne daŭrigas la ingon

TCP ne konas daŭrigon post adresŝanĝo. La SSH-konekto estas identigita per ambaŭ finpunktoj, kaj kiam la tunelo rekonstruiĝas, la loka adreso povas ŝanĝiĝi kaj la malnova ingo estas morta. La servilo rimarkas tion fine, sed via terminalo rimarkas ĝin tuj.

Klientflanka keepalive trovas mortan partneron pli frue. Ĝi ne revenigas la kunsidon, kaj ĝi ne povas rekuperi komandon, kiu jam ruliĝis. La keepalive estas detektilo, ne rekuperilo. Ĝi diras nenion pri tio, ĉu la fora komando postvivis.

Metu la laboron sur la foran gastiganton

Kreu la kunsidon sur la fora gastiganto, ne sur la tekkomputilo. Konektiĝu kiel kutime, startigu tmux tie, kaj rulu la redaktilon aŭ la migradon ene de ĝi. Malkonektu per la defaŭlta prefikso kaj la kunsido daŭre ruliĝas dum la SSH-konekto malaperas. Startigi tmux loke protektas vian ŝelon kontraŭ fermita fenestro, ne foran komandon kontraŭ morta tunelo.

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

Post kiam la VPN revenos, malfermu novan SSH-konekton al la sama gastiganto kaj re-aligu vin per la nomo. La daŭra objekto estas la kunsido, ne la konekto. Donu al ĝi nomon, kiun vi ankoraŭ rekonos post semajno.

tmux kontraŭ task-plenumilo

tmux tenas interagan procezon viva dum la gastiganto funkcias. Task-plenumilo aŭ serv-administranto tenas neinteragan taskon viva, registras ĝian elirstaton, kaj postvivas la tute finiĝon de la SSH-kunsido. La unua estas por laboro, kiun vi observas; la dua por laboro, kiun vi planas kaj poste inspektas.

Nek unu postvivas restartigon, krom se la gastiganto estas agordita por restarigi ĝin. tmux-kunsido mortas kun la maŝino, kaj pasema tasko mortas kun la starto, krom se ĝi estis registrita kiel unuo. Elektu laŭ tio, kion la laboro devas postvivi.

Ambaŭ aliroj ankaŭ bezonas protokolon, kiun vi povas legi post rekonekto. Sen ĝi vi scias, ke la procezo ekzistas, sed ne kion ĝi faris. Skribu la protokolan vojon apud la kunsida nomo.

Decidu laŭ tio, kio devas postvivi

Decidu laŭ la plej malbona afero, kiu povas okazi se la laboro haltas duonvoje. Redaktila kunsido perdas nekonservitajn bufrojn, kio estas ĝena sed rekuperebla. Migrado, kiu fiksas duonon de siaj ŝanĝoj, ne estas, kaj tio argumentas por plenumilo kun registrita rezulto. Se la tasko estas interaga kaj longa, tmux plus skribita protokolo kutime sufiĉas.

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

Kion ajn vi elektos, inspektu la registritan rezulton antaŭ ol relanĉi ion ajn. Manka lasta linio diras al vi, kion vidis la tekkomputilo, ne kion fiksis la servilo. Ĝuste tiu distingo estas la kialo teni la laboron ekster la konekto dekomence, kaj la modelo de malkonekto kaj realigo estas la plej malgranda versio de tio.