vim fryser over SSH? Tjek stty, før du giver VPN skylden

Sessions som denne forbliver forbundet, mens editoren starter, og derefter holder skærmen op med at opdatere, selv om SSH-processen tydeligt er i live. Tastning giver intet, Ctrl-C ser ud til ikke at gøre noget, og den oplagte konklusion er, at VPN'en tabte noget. Det meste af tiden er tunnelen fin, og den fjerne pseudoterminal er i en tilstand, som ingen havde tænkt sig, fordi echo, kanonisk input og flowkontrol bor i terminalen og ikke i netværket. At finde ud af, hvilken af de tre der flyttede sig, er et arbejde på to kommandoer.

Frysningen bor i terminalen, ikke i tunnelen

En pseudoterminal bærer mere end bytes. Den holder linjedisciplinflag, som afgør, om input bliver ekkoet, om læsninger venter på en ny linje, om visse tegn genererer signaler, og om output kan stoppes af et kontroltegn. En interaktiv editor skifter den terminal til rå tilstand i hele perioden og forventes at gendanne de tidligere indstillinger ved afslutning. Når gendannelsen ikke sker, er det shell, du vender tilbage til, ikke det shell, du forlod, selv om forbindelsen aldrig blev afbrudt.

Sammenlign terminaler, før du konkluderer noget. En anden session med den samme editor beviser, at klienten og vejen kan udføre arbejdet; det siger intet om den terminal, hvis flag er ødelagte.

Læs indstillingerne på den terminal, der frøs

Identificer først enheden, og læs derefter begge former for dens tilstand. Den læsbare form viser, hvad der er sat, og maskinformen er den, du kan føde tilbage senere.

tty
stty -a
stty -g

Tre flaggrupper forklarer de fleste af disse rapporter. Echoindstillinger afgør, om tastetryk overhovedet vises, så en terminal med echo slået fra ser død ud, mens shellen modtager hvert tegn. Kanonisk tilstand afgør, om et program ser input én linje ad gangen, så en terminal efterladt i kanonisk tilstand får en applikation i rå tilstand til at virke, som om den ignorerer taster indtil Enter. Flowkontrolindstillinger afgør, om terminalen adlyder XON- og XOFF-tegn, og den gruppe producerer den mest overbevisende falske frysning af de tre.

Registrer output, før du ændrer noget, især når sessionen bærer brugerdefinerede tastebindinger, som nogen er afhængige af. Maskinformen er den sikreste registrering, med det forbehold, at den er implementeringsspecifik og bør gendannes af samme slags system, som producerede den.

Reparer den ene terminal, ikke den session du skriver i

Den standardreparation gendanner den sunde profil, som manualsiden lister, og den påvirker kun én terminal. Hvis editoren stadig holder ugemt arbejde i den terminal, så lad den være, indtil arbejdet er gemt.

Fra en anden shell rettes der eksplicit mod den frosne enhed, så terminalen, du arbejder i, forbliver urørt.

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

En tom skærm med en ødelagt visning er et andet problem end brudt linjedisciplin, og reset-programmet håndterer det ved at udsende terminalinitialiseringssekvenser. Prøv tilstandsreparationen først, fordi den ændrer indstillinger, du kan inspicere, mens reset-sekvensen omskriver skærmen og intet forklarer om, hvordan den brød.

Ctrl-S-fælden bag en overbevisende frysning

Når softwareflowkontrol er aktiveret og de sædvanlige tegn er tildelt, fortæller Ctrl-S terminalen at stoppe med at sende output, og Ctrl-Q fortæller den at fortsætte. Sessionen forbliver i live hele tiden, et enkelt Ctrl-Q er ofte hele reparationen, og der vises intet i nogen log, og det er sådan, denne frysning overlever så mange eskaleringer.

Inspicér de faktiske indstillinger i stedet for at antage dem. Start- og stoptegnene kan omtildeles eller deaktiveres, og en terminal med flowkontrol slået fra reagerer ikke på nogen af dem.

Hvis tilstanden vender tilbage, eller SSH selv går i stå

En tilbagevendende dårlig tilstand peger på noget, der ændrer flagene uden at gendanne dem: en opstartsfil, et indpakningsscript, en multiplexer, der nulstiller det forkerte vindue, eller en applikation, der dør, mens den holder rå tilstand. Tilføj et betinget tjek, der rapporterer tilstanden i stedet for en ubetinget nulstilling, fordi en blanket nulstilling skjuler årsagen og kan tilsidesætte bevidste indstillinger.

Når almindelig SSH-trafik også går i stå, eller reparationen ikke ændrer noget, holder terminalen op med at være den mistænkte.

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

En fastlåsning, der kun vises under store overførsler, tyder på et MTU-problem på vejen, mens en, der også sluger enkelte tastetryk, peger på vejen eller serveren snarere end på pakkestørrelsen. Hold terminalbeviserne adskilt fra netværksbeviserne, fordi en fungerende editor i en anden session ikke er bevis for, at den første terminal nogensinde var sund.