SSH پر vim جم جاتا ہے؟ VPN کو قصوروار ٹھہرانے سے پہلے stty دیکھیں
SSH پر جمے ہوئے ایڈیٹر کا مسئلہ عام طور پر ٹرمینل کی حالت کا ہوتا ہے، ٹوٹی ہوئی سرنگ کا نہیں۔ درست سیوڈو-ٹرمینل پر stty پڑھیں، پھر صرف اسی کی مرمت کریں۔
ایسے سیشن ایڈیٹر کے شروع ہوتے وقت جڑے رہتے ہیں، پھر اسکرین اپ ڈیٹ ہونا بند کر دیتی ہے حالانکہ SSH عمل واضح طور پر زندہ ہے۔ ٹائپ کرنے سے کچھ نہیں آتا، Ctrl-C کچھ نہیں کرتا دکھتا ہے، اور واضح نتیجہ یہ ہے کہ VPN نے کچھ گرا دیا۔ زیادہ تر وقت سرنگ ٹھیک ہوتی ہے اور دور کا سیوڈو-ٹرمینل ایسی حالت میں ہوتا ہے جس کا کسی نے ارادہ نہیں کیا، کیونکہ ایکو، کینونیکل ان پٹ اور بہاؤ کنٹرول نیٹ ورک میں نہیں، ٹرمینل میں رہتے ہیں۔ ان تینوں میں سے کون سا ہلا، یہ جاننا دو کمانڈوں کا کام ہے۔
جمنا سرنگ میں نہیں، ٹرمینل میں رہتا ہے
سیوڈو-ٹرمینل بائٹس سے زیادہ ڈھوتا ہے۔ یہ لائن نظم کے جھنڈے رکھتا ہے جو طے کرتے ہیں کہ ان پٹ ایکو ہوتا ہے یا نہیں، پڑھائی نئی لائن کا انتظار کرتی ہے یا نہیں، بعض حروف سگنل بناتے ہیں یا نہیں، اور کنٹرول حرف سے آؤٹ پٹ روکی جا سکتی ہے یا نہیں۔ انٹرایکٹو ایڈیٹر اس ٹرمینل کو پورے عرصے کے لیے خام موڈ میں ڈالتا ہے اور باہر نکلتے وقت پچھلی ترتیبات بحال کرنے کی توقع ہے۔ جب بحالی نہ ہو، تو آپ جس شیل میں واپس آتے ہیں وہ آپ کا چھوڑا ہوا شیل نہیں ہوتا، خواہ کنکشن کبھی نہ ٹوٹا ہو۔
کوئی بھی نتیجہ اخذ کرنے سے پہلے ٹرمینل کا موازنہ کریں۔ وہی ایڈیٹر چلانے والا دوسرا سیشن ثابت کرتا ہے کہ کلائنٹ اور راستہ کام کر سکتے ہیں؛ جھنڈے ٹوٹے ٹرمینل کے بارے میں یہ کچھ نہیں کہتا۔
جمے ہوئے ٹرمینل پر ترتیبات پڑھیں
پہلے ڈیوائس کی شناخت کریں، پھر اس کی حالت کی دونوں صورتیں پڑھیں۔ پڑھی جانے والی صورت دکھاتی ہے کہ کیا سیٹ ہے، اور مشینی صورت وہ ہے جو آپ بعد میں واپس دے سکتے ہیں۔
tty
stty -a
stty -g
تین جھنڈا گروہ ان میں سے بیشتر رپورٹوں کی وضاحت کرتے ہیں۔ ایکو ترتیبات طے کرتی ہیں کہ کی اسٹروک بالکل دکھتے ہیں یا نہیں، اس لیے ایکو بند ٹرمینل مردہ دکھتا ہے جبکہ شیل ہر حرف وصول کر رہا ہوتا ہے۔ کینونیکل موڈ طے کرتا ہے کہ پروگرام ان پٹ ایک وقت میں ایک لائن دیکھتا ہے یا نہیں، اس لیے کینونیکل موڈ میں چھوڑا گیا ٹرمینل خام موڈ کی ایپلیکیشن کو Enter تک کلیدیں نظرانداز کرتا ہوا دکھاتا ہے۔ بہاؤ کنٹرول ترتیبات طے کرتی ہیں کہ ٹرمینل XON اور XOFF حروف کی پابندی کرتا ہے یا نہیں، اور یہی گروہ تینوں میں سب سے زیادہ قائل جعلی جمنا پیدا کرتا ہے۔
کچھ بدلنے سے پہلے آؤٹ پٹ ریکارڈ کریں، خاص طور پر جب سیشن میں کسی کے بھروسے والی حسب ضرورت کلید بائنڈنگ ہوں۔ مشینی صورت سب سے محفوظ ریکارڈ ہے، اس شرط کے ساتھ کہ یہ عمل درآمد پر منحصر ہے اور اسے اسی نوعیت کے نظام نے بحال کرنا چاہیے جس نے اسے بنایا۔
اسی ایک ٹرمینل کی مرمت کریں، جس سیشن میں آپ ٹائپ کر رہے ہیں اس کی نہیں
معیاری مرمت مینوئل صفحے میں درج صحت مند پروفائل بحال کرتی ہے، اور یہ صرف ایک ٹرمینل پر اثر ڈالتی ہے۔ اگر ایڈیٹر کے پاس اس ٹرمینل میں ابھی غیر محفوظ کام ہے، تو کام محفوظ ہونے تک اسے چھوڑ دیں۔
کسی دوسرے شیل سے، جمے ہوئے ڈیوائس کو واضح طور پر نشانہ بنائیں تاکہ آپ جس ٹرمینل میں کام کر رہے ہیں وہ اچھوتا رہے۔
stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane
خراب ڈسپلے والی خالی اسکرین ٹوٹی لائن نظم سے الگ مسئلہ ہے، اور reset پروگرام ٹرمینل کی ابتدائی ترتیبیں بھیج کر اس کا حل کرتا ہے۔ پہلے حالت کی مرمت آزمائیں، کیونکہ یہ ایسی ترتیبات بدلتی ہے جن کا آپ معائنہ کر سکتے ہیں، جبکہ reset ترتیب اسکرین دوبارہ لکھتی ہے اور یہ نہیں بتاتی کہ یہ کیسے ٹوٹی۔
قائل جمنا کے پیچھے Ctrl-S کا جال
جب سافٹ ویئر بہاؤ کنٹرول فعال ہو اور معمول کے حروف تفویض ہوں، تو Ctrl-S ٹرمینل کو کہتا ہے کہ آؤٹ پٹ بھیجنا بند کرے اور Ctrl-Q دوبارہ شروع کرنے کو کہتا ہے۔ سیشن پورے وقت زندہ رہتا ہے، ایک ہی Ctrl-Q اکثر پوری مرمت ہوتا ہے، اور کسی لاگ میں کچھ نظر نہیں آتا، اور اسی طرح یہ جمنا اتنے بڑھاؤ سے بچ جاتا ہے۔
فرض کرنے کے بجائے اصل ترتیبات کا معائنہ کریں۔ شروع اور روکنے والے حروف دوبارہ تفویض یا غیر فعال کیے جا سکتے ہیں، اور بہاؤ کنٹرول بند ٹرمینل دونوں میں سے کسی کو جواب نہیں دے گا۔
اگر حالت واپس آئے، یا SSH خود اٹک جائے
بار بار آنے والی خراب حالت کسی ایسی چیز کی طرف اشارہ کرتی ہے جو جھنڈے بدلتی ہے مگر بحال نہیں کرتی: اسٹارٹ اپ فائل، ریپر اسکرپٹ، غلط ونڈو ری سیٹ کرنے والا ملٹی پلیکسر، یا خام موڈ پکڑے ہوئے مرنے والی ایپلیکیشن۔ بغیر شرط ری سیٹ کے بجائے حالت کی رپورٹ کرنے والی مشروط جانچ شامل کریں، کیونکہ وسیع ری سیٹ وجہ چھپاتی ہے اور جان بوجھ کر کی گئی ترتیبات کو نظرانداز کر سکتی ہے۔
جب عام SSH ٹریفک بھی اٹک جائے، یا مرمت کچھ نہ بدلے، ٹرمینل مشتبہ رہنا چھوڑ دیتا ہے۔
ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com
صرف بڑی منتقلی کے دوران ظاہر ہونے والا اٹکاؤ راستے کے MTU مسئلے کی نشاندہی کرتا ہے، جبکہ جو اکیلے کی اسٹروک بھی نگل جائے وہ پیکٹ کے حجم کی نہیں، راستے یا سرور کی طرف اشارہ کرتا ہے۔ ٹرمینل کے شواہد کو نیٹ ورک کے شواہد سے الگ رکھیں، کیونکہ دوسرے سیشن میں کام کرنے والا ایڈیٹر اس بات کا ثبوت نہیں کہ پہلا ٹرمینل کبھی صحت مند تھا۔