Az SSH-munkamenet meghal a VPN-nel: tmux vagy feladatfuttató?

A VPN-jelző zöldre vált, az útvonal visszatér, és az a SSH-ablak, amelyet nyitva hagyott, soha többé nem ad vissza parancssort. Egy útvonal helyreállítása nem állítja helyre a használó TCP-beszélgetést, így minden, amit abba az ablakba gépeltek, elveszett. Ha az igazi aggodalom egy szerkesztő puffere vagy egy hosszú migráció, a megoldás az, hogy ne kösse tovább ezt a munkát egyetlen kapcsolathoz. A tmux és egy feladatfuttató a probléma különböző felét oldja meg.

Az újracsatlakozott VPN nem folytatja a csatornát

A TCP nem ismeri a folytatást címváltozás után. Az SSH-kapcsolatot mindkét végpont azonosítja, és amikor az alagút újraépül, a helyi cím megváltozhat, a régi csatorna pedig halott. A kiszolgáló végül észreveszi, a terminálja viszont azonnal.

Egy kliensoldali keepalive hamarabb észleli a halott partnert. Nem hozza vissza a munkamenetet, és nem tud helyreállítani egy már futó parancsot. A keepalive észlelő, nem helyreállító eszköz. Semmit sem mond arról, túlélte-e a távoli parancs.

Tegye a munkát a távoli gazdagépre

A munkamenetet a távoli gazdagépen hozza létre, ne a laptopon. Csatlakozzon szokás szerint, indítsa el ott a tmuxot, és futtassa benne a szerkesztőt vagy a migrációt. Váljon le az alapértelmezett előtaggal, és a munkamenet tovább fut, miközben az SSH-kapcsolat eltűnik. A tmux helyi indítása a héját védi egy bezárt ablaktól, nem egy távoli parancsot egy halott alagúttól.

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

Amikor a VPN visszatér, nyisson új SSH-kapcsolatot ugyanahhoz a gazdagéphez, és csatlakozzon újra név szerint. A tartós objektum a munkamenet, nem a kapcsolat. Adjon neki olyan nevet, amelyet egy hét múlva is felismer.

tmux kontra feladatfuttató

A tmux életben tart egy interaktív folyamatot, amíg a gazdagép fut. A feladatfuttató vagy szolgáltatáskezelő életben tart egy nem interaktív feladatot, rögzíti a kilépési állapotát, és túléli az SSH-munkamenet teljes befejeződését. Az első a figyelt munkához való, a második az ütemezett és később ellenőrzött munkához.

Egyik sem éli túl az újraindítást, hacsak a gazdagép nincs beállítva a helyreállítására. A tmux-munkamenet meghal a géppel, az átmeneti feladat pedig meghal a rendszerindítással, hacsak nem regisztrálták egységként. Aszerint válasszon, amit a munkának túl kell élnie.

Mindkét megközelítéshez napló is kell, amelyet újracsatlakozás után olvashat. Nélküle tudja, hogy a folyamat létezik, de azt nem, mit tett. Írja fel a napló útvonalát a munkamenet neve mellé.

Aszerint döntsön, minek kell túlélnie

Aszerint döntsön, mi a legrosszabb, ami történhet, ha a munka félúton megáll. Egy szerkesztő-munkamenet elveszíti a mentetlen puffereket, ami bosszantó, de helyreállítható. Egy migráció, amely a változásai felét véglegesíti, nem az, és ez a rögzített eredményű futtató mellett szól. Ha a feladat interaktív és hosszú, a tmux és egy írott napló általában elég.

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

Bármit is választ, a rögzített eredményt nézze meg, mielőtt bármit újraindít. Egy hiányzó utolsó sor azt mondja meg, mit látott a laptop, nem azt, mit véglegesített a kiszolgáló. Ez a különbség az oka annak, hogy a munkát eleve a kapcsolaton kívül tartsa, és a a leválasztás és újracsatlakozás modellje ennek a legkisebb változata.