vim зависає через SSH? Перевірте stty, перш ніж звинувачувати VPN

Такі сеанси залишаються підключеними, поки редактор запускається, а потім екран перестає оновлюватися, хоча процес 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 на шляху, а те, що ковтає й одиночні натискання, вказує на шлях або сервер, а не на розмір пакета. Тримайте докази термінала окремо від доказів мережі, бо працюючий редактор у другому сеансі не доводить, що перший термінал колись був здоровим.