SSH-sessie sterf saam met die VPN: tmux of 'n taakuitvoerder?

Jou VPN-aanwyser word groen, die roete is terug, en die SSH-venster wat jy oopgelaat het, gee nooit weer 'n opdragteken nie. Om 'n pad te herstel herstel nie die TCP-gesprek wat dit gebruik het nie, so enigiets wat in daardie venster getik is, is weg. As die werklike kommer 'n redigeerderbuffer of 'n lang migrasie is, is die oplossing om op te hou om daardie werk aan een verbinding te bind. tmux en 'n taakuitvoerder los verskillende helftes van daardie probleem op.

Herverbinde VPN hervat nie die sok nie

TCP het geen begrip daarvan om ná 'n adresverandering te hervat nie. Die SSH-verbinding word deur beide eindpunte geïdentifiseer, en wanneer die tonnel herbou word, kan die plaaslike adres verander en die ou sok is dood. Die bediener merk dit uiteindelik op, maar jou terminale merk dit dadelik op.

Die kliëntkeepalive bespeur 'n dooie eweknie vinniger. Dit bring nie die sessie terug nie, en dit kan nie 'n opdrag herstel wat reeds aan die loop was nie. Die keepalive is 'n opspoorder, nie 'n herstelwerktuig nie. Dit sê niks oor of die afgeleë opdrag oorleef het nie.

Sit die werk op die afgeleë gasheer

Skep die sessie op die afgeleë gasheer, nie op die skootrekenaar nie. Maak soos gewoonlik verbinding, begin tmux daar, en laat die redigeerder of migrasie daarin loop. Ontkoppel met die verstekvoorvoegsel en die sessie bly loop terwyl die SSH-verbinding weggaan. Om tmux plaaslik te begin beskerm jou skulp teen 'n geslote venster, nie 'n afgeleë opdrag teen 'n dooie tonnel nie.

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

Nadat die VPN terug is, maak 'n nuwe SSH-verbinding na dieselfde gasheer oop en heg weer aan by die naam. Die sessie is die duursame objek, nie die verbinding nie. Gee dit 'n naam wat jy 'n week later nog sal herken.

tmux teenoor 'n taakuitvoerder

tmux hou 'n interaktiewe proses lewendig terwyl die gasheer aan bly. 'n Taakuitvoerder of diensbestuurder hou 'n nie-interaktiewe taak lewendig, teken die uitgangstatus daarvan aan, en oorleef dat die SSH-sessie heeltemal eindig. Die eerste is vir werk wat jy dophou; die tweede is vir werk wat jy beplan en later inspekteer.

Nie een van die twee oorleef 'n herbegin nie, tensy die gasheer opgestel is om dit te herstel. 'n tmux-sessie sterf saam met die masjien, en 'n kortstondige taak sterf saam met die opstart, tensy dit as 'n eenheid geregistreer is. Kies volgens wat die werk moet oorleef.

Beide benaderings het ook 'n log nodig wat jy ná herverbinding kan lees. Sonder een weet jy dat die proses bestaan, maar nie wat dit gedoen het nie. Skryf die logpad neer langs die sessienaam.

Besluit volgens wat moet oorleef

Besluit volgens die ergste ding wat kan gebeur as die werk halfpad stop. 'n Redigeerdersessie verloor ongestoorde buffers, wat irriterend maar herstelbaar is. 'n Migrasie wat die helfte van sy veranderinge vaslê, is nie, en dit pleit vir 'n uitvoerder met 'n aangetekende uitkoms. As die taak interaktief en lank is, is tmux plus 'n geskrewe log gewoonlik genoeg.

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

Wat jy ook al kies, inspekteer die aangetekende uitkoms voordat jy enigiets weer laat loop. 'n Ontbrekende laaste reël vertel jou wat die skootrekenaar gesien het, nie wat die bediener vasgelê het nie. Daardie onderskeid is die rede om die werk van die begin af van die verbinding af te hou, en die ontkoppel-en-heg-weer-model is die kleinste weergawe daarvan.