هل يتجمد vim عبر SSH؟ افحص stty قبل لوم الـ VPN
محرر متجمد عبر 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 في المسار، بينما الذي يبتلع أيضًا ضغطات مفردة يشير إلى المسار أو الخادم لا إلى حجم الحزمة. أبقِ أدلة الطرفية منفصلة عن أدلة الشبكة، لأن محررًا يعمل في جلسة ثانية ليس دليلًا على أن الطرفية الأولى كانت سليمة يومًا.