Seja SSH umre skupaj z VPN: tmux ali izvajalec opravil?
Ponovno povezan tunel ne oživi stare vtičnice SSH. Odločite se, ali delo potrebuje terminalsko sejo, na katero se znova priključite, ali opravilo z zabeleženim izidom.
Kazalnik VPN postane zelen, pot je nazaj, in okno SSH, ki ste ga pustili odprto, nikoli več ne vrne poziva. Obnovitev poti ne obnovi pogovora TCP, ki jo je uporabljal, zato je vse, kar je bilo vpisano v tisto okno, izgubljeno. Če je prava skrb medpomnilnik urejevalnika ali dolga migracija, je rešitev v tem, da to delo prenehate vezati na eno povezavo. tmux in izvajalec opravil rešujeta različni polovici te težave.
Ponovno povezan VPN ne nadaljuje vtičnice
TCP ne pozna nadaljevanja po spremembi naslova. Povezava SSH je določena z obema koncema, in ko se tunel znova zgradi, se lokalni naslov lahko spremeni, stara vtičnica pa je mrtva. Strežnik to opazi na koncu, vaš terminal pa takoj.
Odjemalski keepalive prej zazna mrtvega partnerja. Seje ne vrne in ne more obnoviti ukaza, ki je že tekel. Keepalive je zaznavalo, ne orodje za obnovitev. Nič ne pove o tem, ali je oddaljeni ukaz preživel.
Delo postavite na oddaljeni gostitelj
Sejo ustvarite na oddaljenem gostitelju, ne na prenosniku. Povežite se kot običajno, tam zaženite tmux in v njem zaženite urejevalnik ali migracijo. Odklopite se s privzetim predpono in seja teče naprej, medtem ko povezava SSH izgine. Zagon tmuxa lokalno zaščiti vašo lupino pred zaprtim oknom, ne pa oddaljenega ukaza pred mrtvim tunelom.
ssh [email protected]
tmux new-session -s office-workKo se VPN vrne, odprite novo povezavo SSH do istega gostitelja in se znova priključite po imenu. Trajni objekt je seja, ne povezava. Dajte ji ime, ki ga boste prepoznali tudi po enem tednu.
tmux proti izvajalcu opravil
tmux ohranja interaktivni proces živ, dokler je gostitelj vklopljen. Izvajalec opravil ali upravitelj storitev ohranja neinteraktivno opravilo živo, zabeleži njegov izhodni status in preživi popolno končanje seje SSH. Prvi je za delo, ki ga opazujete; drugi za delo, ki ga načrtujete in pozneje pregledate.
Nobeno od obeh ne preživi ponovnega zagona, razen če je gostitelj nastavljen, da ga obnovi. Seja tmux umre s strojem, prehodno opravilo pa umre z zagonom, razen če je bilo registrirano kot enota. Izberite glede na to, kaj mora delo preživeti.
Oba pristopa potrebujeta tudi dnevnik, ki ga lahko berete po ponovni povezavi. Brez njega veste, da proces obstaja, ne pa, kaj je naredil. Zapišite pot do dnevnika ob imenu seje.
Odločite se glede na to, kaj mora preživeti
Odločite se glede na najhujše, kar se lahko zgodi, če se delo ustavi na pol poti. Seja urejevalnika izgubi neshranjene medpomnilnike, kar je nadležno, a obnovljivo. Migracija, ki uveljavi polovico svojih sprememb, ni, in to govori v prid izvajalcu z zabeleženim izidom. Če je opravilo interaktivno in dolgo, tmux in zapisan dnevnik običajno zadostujeta.
systemd-run --user --unit=migrate-customers --collect ./migrate.shKarkoli izberete, preden kar koli znova zaženete, pregledajte zabeleženi izid. Manjkajoča zadnja vrstica vam pove, kaj je videl prenosnik, ne kaj je potrdil strežnik. Prav ta razlika je razlog, da delo od začetka držite zunaj povezave, in model odklopa in ponovnega priklopa je njegova najmanjša različica.