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