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