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 проблем на патеката, додека оној што голта и поединечни притискања укажува на патеката или серверот, а не на големината на пакетот. Држете ги доказите од терминалот одделно од мрежните докази, бидејќи уредувач што работи во втора сесија не е доказ дека првиот терминал некогаш бил здрав.