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

جو بھی چنیں، کچھ بھی دوبارہ چلانے سے پہلے ریکارڈ شدہ نتیجہ دیکھیں۔ آخری سطر کا نہ ہونا بتاتا ہے کہ لیپ ٹاپ نے کیا دیکھا، یہ نہیں کہ سرور نے کیا کمٹ کیا۔ یہی فرق کام کو شروع سے کنکشن سے باہر رکھنے کی وجہ ہے، اور ڈیٹیچ اور دوبارہ اٹیچ کا ماڈل اُس کی سب سے چھوٹی شکل ہے۔