vim روی SSH یخ می‌زند؟ پیش از سرزنش VPN، stty را بررسی کنید

نشست‌هایی مانند این هنگام شروع ویرایشگر متصل می‌مانند، سپس صفحه به‌روزرسانی نمی‌شود حتی با اینکه فرایند SSH آشکارا زنده است. تایپ کردن چیزی تولید نمی‌کند، Ctrl-C به نظر می‌رسد کاری نمی‌کند، و نتیجه‌گیری آشکار این است که VPN چیزی را انداخته است. بیشتر وقت‌ها تونل سالم است و شبه‌ترمینال راه دور در وضعیتی است که هیچ‌کس قصدش را نداشته، چون echo، ورودی متعارف و کنترل جریان در ترمینال زندگی می‌کنند نه در شبکه. فهمیدن اینکه کدام یک از این سه جابه‌جا شده کاری با دو فرمان است.

یخ‌زدگی در ترمینال زندگی می‌کند، نه در تونل

شبه‌ترمینال بیش از بایت‌ها حمل می‌کند. پرچم‌های نظم خط را نگه می‌دارد که تعیین می‌کنند آیا ورودی بازتاب می‌شود، آیا خواندن‌ها منتظر خط جدید می‌مانند، آیا نویسه‌های خاص سیگنال تولید می‌کنند، و آیا خروجی را می‌توان با نویسه کنترل متوقف کرد. ویرایشگر تعاملی آن ترمینال را برای تمام مدت به حالت خام می‌برد و انتظار می‌رود هنگام خروج تنظیمات قبلی را بازگرداند. وقتی بازگردانی رخ نمی‌دهد، پوسته‌ای که به آن بازمی‌گردید همان پوسته‌ای نیست که ترک کردید، حتی اگر اتصال هرگز قطع نشده باشد.

پیش از هر نتیجه‌گیری ترمینال‌ها را مقایسه کنید. نشست دومی که همان ویرایشگر را اجرا می‌کند اثبات می‌کند که کلاینت و مسیر می‌توانند کار را انجام دهند؛ درباره ترمینالی که پرچم‌هایش خراب است چیزی نمی‌گوید.

تنظیمات را روی ترمینالی که یخ زد بخوانید

ابتدا دستگاه را شناسایی کنید، سپس هر دو شکل وضعیت آن را بخوانید. شکل خوانا نشان می‌دهد چه چیزی تنظیم شده، و شکل ماشینی همان است که می‌توانید بعداً بازگردانید.

tty
stty -a
stty -g

سه گروه پرچم بیشتر این گزارش‌ها را توضیح می‌دهند. تنظیمات echo تعیین می‌کند که فشار دادن کلیدها اصلاً دیده می‌شود یا نه، پس ترمینالی با echo خاموش مرده به نظر می‌رسد در حالی که پوسته هر نویسه را دریافت می‌کند. حالت متعارف تعیین می‌کند که برنامه ورودی را یک خط در هر بار ببیند، پس ترمینالی که در حالت متعارف رها شده باعث می‌شود برنامه‌ای در حالت خام تا 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 مسیر است، در حالی که یکی که فشارهای تکی را هم می‌بلعد به مسیر یا سرور اشاره دارد نه به اندازه بسته. شواهد ترمینال را از شواهد شبکه جدا نگه دارید، چون ویرایشگر کارکننده در نشست دوم مدرکی بر سالم بودن ترمینال اول در گذشته نیست.