vim zamrzne cez SSH? Skontrolujte stty, kým obviníte VPN
Zamrznutý editor cez SSH je zvyčajne problém stavu terminálu, nie prerušený tunel. Prečítajte stty na správnom pseudotermináli a opravte iba ten.
Takéto relácie zostávajú pripojené, kým sa editor spúšťa, a potom sa obrazovka prestane obnovovať, hoci proces SSH je zjavne živý. Písanie nič neprináša, Ctrl-C vyzerá, že nič nerobí, a zjavný záver je, že VPN niečo zahodilo. Väčšinou je tunel v poriadku a vzdialený pseudoterminál je v stave, ktorý nikto nezamýšľal, pretože echo, kanonický vstup a riadenie toku žijú v termináli, nie v sieti. Zistiť, ktorý z tých troch sa posunul, je práca na dva príkazy.
Zmrznutie žije v termináli, nie v tuneli
Pseudoterminál nesie viac ako bajty. Drží príznaky disciplíny riadka, ktoré rozhodujú, či sa vstup zobrazuje, či čítania čakajú na nový riadok, či určité znaky generujú signály a či možno výstup zastaviť riadiacim znakom. Interaktívny editor prepne tento terminál na čas behu do surového režimu a pri ukončení má obnoviť predchádzajúce nastavenia. Keď k obnoveniu nedôjde, shell, do ktorého sa vrátite, nie je shell, ktorý ste opustili, aj keď sa spojenie nikdy neprerušilo.
Porovnajte terminály, kým niečo uzavriete. Druhá relácia s tým istým editorom dokazuje, že klient aj cesta prácu zvládnu; o termináli, ktorého príznaky sú pokazené, to nehovorí nič.
Prečítajte nastavenia na termináli, ktorý zamrzol
Najprv určte zariadenie, potom prečítajte obe podoby jeho stavu. Čitateľná podoba ukazuje, čo je nastavené, a strojová podoba je tá, ktorú môžete neskôr vrátiť.
tty
stty -a
stty -g
Tri skupiny príznakov vysvetľujú väčšinu týchto hlásení. Nastavenia echa rozhodujú, či sa stlačenia vôbec objavia, takže terminál s vypnutým echom vyzerá mŕtvy, zatiaľ čo shell prijíma každý znak. Kanonický režim rozhoduje, či program vidí vstup po riadkoch, takže terminál ponechaný v kanonickom režime spôsobí, že aplikácia v surovom režime akoby ignorovala klávesy až do Enteru. Nastavenia riadenia toku rozhodujú, či terminál poslúcha znaky XON a XOFF, a táto skupina vytvára najpresvedčivejšie falošné zmrznutie z troch.
Zaznamenajte výstup, kým čokoľvek zmeníte, najmä keď relácia nesie vlastné klávesové skratky, na ktorých niekto závisí. Strojová podoba je najbezpečnejší záznam, s výhradou, že závisí od implementácie a má ju obnoviť rovnaký druh systému, ktorý ju vytvoril.
Opravte ten jeden terminál, nie reláciu, v ktorej píšete
Štandardná oprava obnoví zdravý profil, ktorý uvádza manuálová stránka, a ovplyvní iba jeden terminál. Ak editor v tom termináli stále drží neuloženú prácu, nechajte ho na pokoji, kým sa práca neuloží.
Z iného shellu zacielte výslovne na zamrznuté zariadenie, aby terminál, v ktorom pracujete, zostal nedotknutý.
stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane
Prázdna obrazovka s poškodeným zobrazením je iný problém než pokazená disciplína riadka a program reset ho rieši vysielaním inicializačných sekvencií terminálu. Skúste najprv opravu stavu, pretože mení nastavenia, ktoré môžete prezrieť, zatiaľ čo sekvencia reset prepisuje obrazovku a nič nevysvetľuje o tom, ako sa pokazila.
Pasca Ctrl-S za presvedčivým zmrznutím
Keď je zapnuté softvérové riadenie toku a obvyklé znaky sú priradené, Ctrl-S povie terminálu, aby prestal odosielať výstup, a Ctrl-Q, aby pokračoval. Relácia zostáva celý čas živá, jediné Ctrl-Q je často celá oprava a v žiadnom logu sa nič neobjaví, a takto toto zmrznutie prežíva toľko eskalácií.
Prezrite si skutočné nastavenia, namiesto toho, aby ste ich predpokladali. Znaky pre štart a zastavenie možno priradiť inam alebo vypnúť, a terminál s vypnutým riadením toku nebude reagovať na ani jeden z nich.
Ak sa stav vráti, alebo ak sa zasekne samotné SSH
Opakovaný zlý stav ukazuje na niečo, čo mení príznaky bez ich obnovenia: spúšťací súbor, obalový skript, multiplexor resetujúci nesprávne okno alebo aplikácia, ktorá umrie, keď drží surový režim. Pridajte podmienenú kontrolu, ktorá hlási stav, namiesto bezpodmienečného resetu, pretože plošný reset skrýva príčinu a môže prepísať zámerné nastavenia.
Keď sa zasekne aj bežná prevádzka SSH, alebo oprava nič nezmení, terminál prestáva byť podozrivým.
ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com
Zaseknutie, ktoré sa objaví len pri veľkých prenosoch, naznačuje problém MTU na ceste, zatiaľ čo také, ktoré prehĺta aj jednotlivé stlačenia, ukazuje na cestu alebo server, nie na veľkosť paketu. Držte dôkazy z terminálu oddelene od sieťových dôkazov, pretože fungujúci editor v druhej relácii nie je dôkaz, že prvý terminál bol niekedy zdravý.