Relácia SSH umiera s VPN: tmux alebo spúšťač úloh?

Indikátor VPN zo zelenie, trasa je späť a okno SSH, ktoré ste nechali otvorené, už nikdy nevráti výzvu. Obnovenie trasy neobnoví konverzáciu TCP, ktorá ju používala, takže všetko, čo ste do toho okna napísali, je preč. Ak je skutočnou starosťou buffer editora alebo dlhá migrácia, riešením je prestať tú prácu viazať na jedno pripojenie. tmux a spúšťač úloh riešia rôzne polovice tohto problému.

Znovu pripojená VPN socket neobnoví

TCP nepozná pojem obnovenia po zmene adresy. Pripojenie SSH je určené oboma koncami, a keď sa tunel znovu postaví, lokálna adresa sa môže zmeniť a starý socket je mŕtvy. Server si to všimne nakoniec, ale váš terminál si to všimne okamžite.

Klientsky keepalive odhalí mŕtvy náprotivok skôr. Reláciu nevráti a nedokáže obnoviť príkaz, ktorý už bežal. Keepalive je detektor, nie nástroj obnovy. Nič nehovorí o tom, či vzdialený príkaz prežil.

Presuňte prácu na vzdialený hostiteľ

Vytvorte reláciu na vzdialenom hostiteľovi, nie na notebooku. Pripojte sa ako obvykle, spustite tam tmux a v ňom spustite editor alebo migráciu. Odpojte sa predvoleným prefixom a relácia beží ďalej, aj keď pripojenie SSH zmizne. Lokálne spustenie tmux ochráni váš shell pred zatvoreným oknom, nie vzdialený príkaz pred mŕtvym tunelom.

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

Keď je VPN späť, otvorte nové pripojenie SSH k rovnakému hostiteľovi a pripojte sa späť podľa názvu. Trvalým objektom je relácia, nie pripojenie. Pomenujte ju tak, aby ste ju poznali aj po týždni.

tmux verzus spúšťač úloh

tmux drží interaktívny proces nažive, kým hostiteľ beží. Spúšťač úloh alebo správca služieb drží neinteraktívnu úlohu nažive, zaznamená jej stav ukončenia a prežije aj úplné skončenie relácie SSH. Prvý je pre prácu, ktorú sledujete; druhý pre prácu, ktorú plánujete a neskôr kontrolujete.

Ani jedno neprežije reštart, ak hostiteľ nie je nastavený na obnovenie. Relácia tmux umiera so strojom a prechodná úloha umiera s bootom, ak nebola zaregistrovaná ako jednotka. Vyberajte podľa toho, čo má práca prežiť.

Oba prístupy potrebujú aj log, ktorý si po opätovnom pripojení prečítate. Bez neho viete, že proces existuje, ale nie čo urobil. Zapíšte cestu k logu vedľa názvu relácie.

Rozhodnite podľa toho, čo musí prežiť

Rozhodujte podľa najhoršieho, čo sa môže stať, ak sa práca zastaví v polovici. Relácia editora stratí neuložené buffery, čo je otravné, ale obnoviteľné. Migrácia, ktorá potvrdí polovicu svojich zmien, nie, a to hovorí v prospech spúšťača so zaznamenaným výsledkom. Ak je úloha interaktívna a dlhá, tmux plus písaný log zvyčajne stačí.

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

Čokoľvek si vyberiete, pred opätovným spustením čohokoľvek si pozrite zaznamenaný výsledok. Chýbajúci posledný riadok vám povie, čo videl notebook, nie čo potvrdil server. Práve ten rozdiel je dôvod držať prácu mimo pripojenia od začiatku, a model odpojenia a opätovného pripojenia je jeho najmenšia verzia.