VPN-നൊപ്പം SSH സെഷൻ മരിക്കുന്നു: tmux അതോ ജോബ് റണ്ണർ?

നിങ്ങളുടെ VPN സൂചകം പച്ചയാകുന്നു, പാത തിരിച്ചുവരുന്നു, എന്നാൽ തുറന്നിട്ട SSH ജാലകം ഒരിക്കലും പ്രോംപ്റ്റ് തിരികെ നൽകുന്നില്ല. ഒരു പാത പുനഃസ്ഥാപിക്കുന്നത് അത് ഉപയോഗിച്ചിരുന്ന TCP സംഭാഷണം പുനഃസ്ഥാപിക്കുന്നില്ല, അതിനാൽ ആ ജാലകത്തിൽ ടൈപ്പ് ചെയ്തതെല്ലാം പോയി. യഥാർത്ഥ ആശങ്ക എഡിറ്ററിന്റെ ബഫർ അല്ലെങ്കിൽ നീണ്ട മൈഗ്രേഷൻ ആണെങ്കിൽ, ആ ജോലി ഒരു ബന്ധത്തിൽ ബന്ധിക്കുന്നത് നിർത്തുകയാണ് പരിഹാരം. tmux-ഉം ജോബ് റണ്ണറും ആ പ്രശ്നത്തിന്റെ വ്യത്യസ്ത പകുതികൾ പരിഹരിക്കുന്നു.

വീണ്ടും ബന്ധിപ്പിച്ച VPN സോക്കറ്റ് തുടരുന്നില്ല

വിലാസം മാറിയതിന് ശേഷം തുടരാം എന്ന ധാരണ TCP-ക്ക് ഇല്ല. SSH ബന്ധം രണ്ട് അറ്റങ്ങളാലും തിരിച്ചറിയപ്പെടുന്നു, ടണൽ വീണ്ടും നിർമ്മിക്കുമ്പോൾ പ്രാദേശിക വിലാസം മാറാം, പഴയ സോക്കറ്റ് മരിച്ചിരിക്കും. സെർവർ അത് ഒടുവിൽ ശ്രദ്ധിക്കും, എന്നാൽ നിങ്ങളുടെ ടെർമിനൽ ഉടൻ ശ്രദ്ധിക്കും.

ക്ലയന്റ് കീപ്പ്അലൈവ് മരിച്ച എതിരാളിയെ വേഗത്തിൽ കണ്ടെത്തുന്നു. അത് സെഷൻ തിരികെ നൽകുന്നില്ല, ഇതിനകം പ്രവർത്തിച്ചിരുന്ന ഒരു കമാൻഡ് വീണ്ടെടുക്കാനും കഴിയില്ല. കീപ്പ്അലൈവ് ഒരു കണ്ടെത്തലാണ്, വീണ്ടെടുപ്പ് ഉപകരണമല്ല. ദൂര കമാൻഡ് അതിജീവിച്ചോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

ജോലി ദൂര ഹോസ്റ്റിൽ വയ്ക്കുക

സെഷൻ ലാപ്ടോപ്പിലല്ല, ദൂര ഹോസ്റ്റിൽ സൃഷ്ടിക്കുക. പതിവുപോലെ ബന്ധിപ്പിച്ച്, അവിടെ tmux തുടങ്ങി, അതിനുള്ളിൽ എഡിറ്ററോ മൈഗ്രേഷനോ പ്രവർത്തിപ്പിക്കുക. സ്ഥിരസ്ഥിതി പ്രിഫിക്സ് ഉപയോഗിച്ച് ഡിറ്റാച്ച് ചെയ്യുക, SSH ബന്ധം പോയാലും സെഷൻ പ്രവർത്തിക്കുന്നു. പ്രാദേശികമായി tmux തുടങ്ങുന്നത് നിങ്ങളുടെ ഷെല്ലിനെ അടഞ്ഞ ജാലകത്തിൽ നിന്ന് സംരക്ഷിക്കുന്നു, ദൂര കമാൻഡിനെ മരിച്ച ടണലിൽ നിന്നല്ല.

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

VPN തിരിച്ചുവന്ന ശേഷം അതേ ഹോസ്റ്റിലേക്ക് പുതിയ SSH ബന്ധം തുറന്ന് പേരിനാൽ വീണ്ടും ബന്ധിക്കുക. നിലനിൽക്കുന്ന വസ്തു സെഷൻ ആണ്, ബന്ധമല്ല. ഒരു ആഴ്ച കഴിഞ്ഞും തിരിച്ചറിയുന്ന ഒരു പേര് നൽകുക.

tmux ജോബ് റണ്ണറിനെതിരെ

ഹോസ്റ്റ് ഓൺ ആയിരിക്കുന്നിടത്തോളം tmux ഒരു ഇന്ററാക്ടീവ് പ്രോസസ് ജീവനോടെ നിർത്തുന്നു. ഒരു ജോബ് റണ്ണർ അല്ലെങ്കിൽ സർവീസ് മാനേജർ ഇന്ററാക്ടീവ് അല്ലാത്ത ജോബ് ജീവനോടെ നിർത്തുന്നു, അതിന്റെ എക്സിറ്റ് നില രേഖപ്പെടുത്തുന്നു, SSH സെഷൻ പൂർണ്ണമായി അവസാനിച്ചാലും അതിജീവിക്കുന്നു. ആദ്യത്തേത് നിങ്ങൾ നിരീക്ഷിക്കുന്ന ജോലിക്കാണ്; രണ്ടാമത്തേത് നിങ്ങൾ ഷെഡ്യൂൾ ചെയ്ത് പിന്നീട് പരിശോധിക്കുന്ന ജോലിക്ക്.

ഹോസ്റ്റ് അത് പുനഃസ്ഥാപിക്കാൻ ക്രമീകരിച്ചിട്ടില്ലെങ്കിൽ രണ്ടും റീബൂട്ടിൽ അതിജീവിക്കുന്നില്ല. tmux സെഷൻ യന്ത്രത്തോടൊപ്പം മരിക്കുന്നു, താൽക്കാലിക ജോബ് യൂണിറ്റായി രജിസ്റ്റർ ചെയ്തിട്ടില്ലെങ്കിൽ ബൂട്ടിനൊപ്പം മരിക്കുന്നു. ജോലി എന്തിനെ അതിജീവിക്കണം എന്നതനുസരിച്ച് തിരഞ്ഞെടുക്കുക.

രണ്ട് സമീപനങ്ങൾക്കും വീണ്ടും ബന്ധിപ്പിച്ച ശേഷം വായിക്കാനാകുന്ന ഒരു ലോഗ് കൂടി വേണം. അതില്ലാതെ പ്രോസസ് ഉണ്ടെന്ന് അറിയാം, പക്ഷേ എന്ത് ചെയ്തുവെന്ന് അറിയില്ല. ലോഗിന്റെ പാത സെഷന്റെ പേരിനരികെ എഴുതിവയ്ക്കുക.

എന്ത് അതിജീവിക്കണം എന്നത് കൊണ്ട് തീരുമാനിക്കുക

ജോലി പകുതിയിൽ നിന്നാൽ സംഭവിക്കാവുന്ന ഏറ്റവും മോശമായതിനെ അടിസ്ഥാനമാക്കി തീരുമാനിക്കുക. എഡിറ്റർ സെഷൻ സേവ് ചെയ്യാത്ത ബഫറുകൾ നഷ്ടപ്പെടുത്തുന്നു, അത് ശല്യമാണെങ്കിലും വീണ്ടെടുക്കാം. തന്റെ മാറ്റങ്ങളുടെ പകുതി കമ്മിറ്റ് ചെയ്യുന്ന മൈഗ്രേഷൻ അങ്ങനെയല്ല, അത് രേഖപ്പെടുത്തിയ ഫലമുള്ള റണ്ണറിന് അനുകൂലമാണ്. ജോബ് ഇന്ററാക്ടീവും ദൈർഘ്യമേറിയതുമാണെങ്കിൽ tmux-ഉം എഴുതിയ ലോഗും സാധാരണയായി മതി.

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

എന്ത് തിരഞ്ഞെടുത്താലും, എന്തെങ്കിലും വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് രേഖപ്പെടുത്തിയ ഫലം പരിശോധിക്കുക. അവസാന വരി ഇല്ലാതിരിക്കുന്നത് ലാപ്ടോപ്പ് എന്ത് കണ്ടു എന്ന് പറയുന്നു, സെർവർ എന്ത് കമ്മിറ്റ് ചെയ്തു എന്നല്ല. ആ വ്യത്യാസമാണ് ജോലി തുടക്കം മുതൽ ബന്ധത്തിന് പുറത്ത് നിർത്താനുള്ള കാരണം, ഡിറ്റാച്ചും വീണ്ടും അറ്റാച്ചും ചെയ്യുന്ന മാതൃക അതിന്റെ ഏറ്റവും ചെറിയ രൂപമാണ്.