vim zamrzá přes SSH? Zkontrolujte stty, než obviníte VPN

Taková sezení zůstávají připojená, dokud se editor spouští, a pak se obrazovka přestane obnovovat, i když je proces SSH zjevně živý. Psaní nic nevrací, Ctrl-C vypadá, že nic nedělá, a zřejmý závěr je, že VPN něco zahodil. Většinu času je tunel v pořádku a vzdálený pseudoterminál je ve stavu, který nikdo nezamýšlel, protože echo, kanonický vstup a řízení toku žijí v terminálu, ne v síti. Zjistit, které z těchto tří se posunulo, je práce na dva příkazy.

Zmrznutí žije v terminálu, ne v tunelu

Pseudoterminál nese víc než bajty. Drží příznaky disciplíny řádku, které rozhodují, zda se vstup zobrazuje, zda čtení čekají na nový řádek, zda určité znaky generují signály a zda lze výstup zastavit řídicím znakem. Interaktivní editor přepne tento terminál na dobu běhu do surového režimu a při ukončení má obnovit předchozí nastavení. Když k obnovení nedojde, shell, do kterého se vrátíte, není shell, který jste opustili, i když se spojení nikdy nepřerušilo.

Porovnejte terminály, než cokoli uzavřete. Druhé sezení se stejným editorem dokazuje, že klient i cesta práci zvládnou; o terminálu, jehož příznaky jsou rozbité, to neříká nic.

Přečtěte nastavení na terminálu, který zamrzl

Nejprve určete zařízení, pak přečtěte obě podoby jeho stavu. Čitelná podoba ukazuje, co je nastaveno, a strojová podoba je ta, kterou můžete později vrátit.

tty
stty -a
stty -g

Tři skupiny příznaků vysvětlují většinu těchto hlášení. Nastavení echa rozhoduje, zda se stisky vůbec objeví, takže terminál s vypnutým echem vypadá mrtvý, zatímco shell přijímá každý znak. Kanonický režim rozhoduje, zda program vidí vstup po řádcích, takže terminál ponechaný v kanonickém režimu způsobí, že aplikace v surovém režimu jako by ignorovala klávesy až do Enteru. Nastavení řízení toku rozhoduje, zda terminál poslouchá znaky XON a XOFF, a tato skupina vytváří nejpřesvědčivější falešné zmrznutí ze všech tří.

Zaznamenejte výstup, než cokoli změníte, zvláště když sezení nese vlastní klávesové zkratky, na kterých někdo závisí. Strojová podoba je nejbezpečnější záznam, s výhradou, že závisí na implementaci a má ji obnovit stejný druh systému, který ji vytvořil.

Opravte ten jeden terminál, ne sezení, ve kterém píšete

Standardní oprava obnoví zdravý profil, který uvádí manuálová stránka, a ovlivní jen jeden terminál. Pokud editor v tom terminálu stále drží neuloženou práci, nechte ho být, dokud se práce neuloží.

Z jiného shellu zacilte výslovně na zamrzlé zařízení, aby terminál, ve kterém pracujete, zůstal nedotčen.

stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane

Prázdná obrazovka s poškozeným zobrazením je jiný problém než rozbitá disciplína řádku a program reset ho řeší vysíláním inicializačních sekvencí terminálu. Zkuste nejprve opravu stavu, protože mění nastavení, která můžete prohlédnout, zatímco sekvence reset přepisuje obrazovku a nic nevysvětluje o tom, jak se rozbila.

Past Ctrl-S za přesvědčivým zmrznutím

Když je zapnuto softwarové řízení toku a obvyklé znaky jsou přiřazeny, Ctrl-S řekne terminálu, aby přestal odesílat výstup, a Ctrl-Q, aby pokračoval. Sezení zůstává celou dobu živé, jediné Ctrl-Q je často celá oprava a v žádném logu se nic neobjeví, a takto toto zmrznutí přežívá tolik eskalací.

Prohlédněte si skutečné nastavení, místo abyste ho předpokládali. Znaky pro start a zastavení lze přiřadit jinam nebo vypnout, a terminál s vypnutým řízením toku nebude reagovat na ani jeden z nich.

Když se stav vrací, nebo když se zasekne samotné SSH

Opakovaný špatný stav ukazuje na něco, co příznaky mění, aniž by je obnovovalo: spouštěcí soubor, obalový skript, multiplexor resetující špatné okno nebo aplikace, která umře, když drží surový režim. Přidejte podmíněnou kontrolu, která stav hlásí, místo bezpodmínečného resetu, protože plošný reset skrývá příčinu a může přepsat záměrná nastavení.

Když se zasekne i běžný provoz SSH, nebo oprava nic nezmění, terminál přestává být podezřelým.

ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com

Zaseknutí, které se objeví jen při velkých přenosech, naznačuje problém MTU na cestě, zatímco takové, které polyká i jednotlivé stisky, ukazuje na cestu nebo server, ne na velikost paketu. Držte důkazy z terminálu oddělené od síťových důkazů, protože fungující editor v druhém sezení není důkaz, že první terminál byl někdy zdravý.