Namatay ang SSH session kasama ng VPN: tmux o job runner?

Nagiging berde ang iyong VPN indicator, bumalik ang ruta, at ang SSH window na iniwan mong bukas ay hindi na kailanman nagbabalik ng prompt. Ang pagpapanumbalik ng ruta ay hindi nagpapanumbalik ng TCP na usapan na gumamit nito, kaya lahat ng naipasok sa window na iyon ay nawala. Kung ang tunay na alalahanin ay buffer ng editor o mahabang migration, ang solusyon ay itigil ang pagtali ng trabahong iyon sa isang koneksyon. Ang tmux at isang job runner ay nilulutas ang magkaibang kalahati ng problemang iyon.

Hindi ipinagpatuloy ng muling nakakonektang VPN ang socket

Walang konsepto ang TCP ng pagpapatuloy pagkatapos magbago ang address. Nakikilala ang SSH connection sa pamamagitan ng dalawang dulo, at kapag muling itinayo ang tunnel, maaaring magbago ang lokal na address at patay na ang lumang socket. Napapansin ito ng server sa huli, ngunit napapansin ito ng iyong terminal agad.

Ang keepalive ng kliyente ay nakakakita ng patay na kapares nang mas maaga. Hindi nito ibinabalik ang session, at hindi nito maibabalik ang command na tumatakbo na. Ang keepalive ay isang detektor, hindi kasangkapan sa pagbawi. Wala itong sinasabi tungkol sa kung nabuhay ang remote na command.

Ilagay ang trabaho sa remote host

Gawin ang session sa remote host, hindi sa laptop. Kumonekta gaya ng dati, simulan ang tmux doon, at patakbuhin ang editor o migration sa loob nito. Mag-detach gamit ang default prefix at patuloy na tumatakbo ang session habang nawawala ang SSH connection. Ang pagsisimula ng tmux nang lokal ay nagpoprotekta sa iyong shell mula sa saradong window, hindi sa remote na command mula sa patay na tunnel.

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

Kapag bumalik ang VPN, magbukas ng bagong SSH connection sa parehong host at muling kumabit ayon sa pangalan. Ang matibay na bagay ay ang session, hindi ang koneksyon. Bigyan ito ng pangalan na makikilala mo pa pagkalipas ng isang linggo.

tmux laban sa isang job runner

Pinapanatiling buhay ng tmux ang isang interactive na proseso habang nakabukas ang host. Pinapanatiling buhay ng job runner o service manager ang isang hindi interactive na job, itinatala ang exit status nito, at nakakaligtas kapag ganap na natapos ang SSH session. Ang una ay para sa trabahong pinapanood mo; ang pangalawa ay para sa trabahong iniiskedyul at sinusuri mo mamaya.

Wala sa dalawa ang nakakaligtas sa reboot maliban kung naka-configure ang host na ibalik ito. Namatay ang tmux session kasama ng makina, at namatay ang pansamantalang job kasama ng boot maliban kung nairehistro ito bilang unit. Pumili ayon sa kailangang lagpasan ng trabaho.

Kailangan din ng dalawang paraan ng log na mababasa mo pagkatapos muling kumonekta. Kung wala iyon, alam mong may proseso, ngunit hindi kung ano ang ginawa nito. Isulat ang path ng log sa tabi ng pangalan ng session.

Magpasya ayon sa dapat mabuhay

Magpasya ayon sa pinakamasamang maaaring mangyari kung titigil ang trabaho sa kalagitnaan. Nawawala ng editor session ang hindi na-save na buffer, na nakakainis ngunit nababawi. Ang migration na nagtatakda ng kalahati ng mga pagbabago nito ay hindi ganoon, at sinusuportahan nito ang isang runner na may naitalang resulta. Kung ang job ay interactive at mahaba, karaniwang sapat ang tmux at nakasulat na log.

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

Anuman ang piliin mo, suriin ang naitalang resulta bago muling patakbuhin ang anuman. Ang nawawalang huling linya ay nagsasabi kung ano ang nakita ng laptop, hindi kung ano ang itinala ng server. Ang pagkakaibang iyon ang dahilan upang ilayo ang trabaho sa koneksyon mula pa sa simula, at ang modelo ng pag-detach at muling pagkabit ang pinakamaliit na bersyon nito.