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