vim fryser over SSH? Sjekk stty før du gir VPN skylden

Sesjoner som dette holder seg tilkoblet mens editoren starter, og deretter slutter skjermen å oppdatere selv om SSH-prosessen tydelig er i live. Tasting gir ingenting, Ctrl-C ser ut til å ikke gjøre noe, og den åpenbare konklusjonen er at VPN-en mistet noe. Som oftest er tunnelen i orden og den eksterne pseudoterminalen er i en tilstand ingen hadde tenkt seg, fordi ekko, kanonisk input og flytkontroll bor i terminalen og ikke i nettet. Å finne ut hvilken av de tre som flyttet seg er en jobb på to kommandoer.

Frysingen bor i terminalen, ikke i tunnelen

En pseudoterminal bærer mer enn bytes. Den holder linjedisiplinflagg som avgjør om input blir ekkoet, om lesinger venter på en ny linje, om visse tegn genererer signaler, og om utdata kan stoppes av et kontrolltegn. En interaktiv editor setter den terminalen i rå modus for hele varigheten og forventes å gjenopprette de forrige innstillingene ved avslutning. Når gjenopprettingen ikke skjer, er skallet du kommer tilbake til ikke skallet du forlot, selv om forbindelsen aldri ble brutt.

Sammenlign terminaler før du konkluderer noe. En annen sesjon med samme editor beviser at klienten og veien kan gjøre jobben; den sier ingenting om terminalen hvis flagg er ødelagte.

Les innstillingene på terminalen som frøs

Identifiser enheten først, og les deretter begge formene for tilstanden. Den lesbare formen viser hva som er satt, og maskinformen er den du kan mate tilbake senere.

tty
stty -a
stty -g

Tre flagggrupper forklarer de fleste av disse rapportene. Ekkoinnstillinger avgjør om tastetrykk i det hele tatt vises, så en terminal med ekko av virker død mens skallet mottar hvert tegn. Kanonisk modus avgjør om et program ser input én linje om gangen, så en terminal som er latt i kanonisk modus får en applikasjon i rå modus til å se ut som den ignorerer taster til Enter. Flytkontrollinnstillinger avgjør om terminalen adlyder tegnene XON og XOFF, og den gruppen produserer den mest overbevisende falske frysingen av de tre.

Registrer utdataen før du endrer noe, spesielt når sesjonen bærer egendefinerte tastebindinger som noen er avhengige av. Maskinformen er den sikreste registreringen, med forbeholdet at den er implementasjonsspesifikk og bør gjenopprettes av samme slags system som produserte den.

Reparer den ene terminalen, ikke sesjonen du skriver i

Standardreparasjonen gjenoppretter den sunne profilen som manualsiden lister, og den påvirker bare én terminal. Hvis editoren fortsatt holder ulagret arbeid i den terminalen, la den være i fred til arbeidet er lagret.

Fra et annet skall, rett deg eksplisitt mot den frosne enheten slik at terminalen du arbeider i forblir urørt.

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

En tom skjerm med ødelagt visning er et annet problem enn brutt linjedisiplin, og reset-programmet håndterer det ved å sende ut terminalinitialiseringssekvenser. Prøv tilstandsreparasjonen først, fordi den endrer innstillinger du kan inspisere, mens reset-sekvensen skriver om skjermen og ikke forklarer noe om hvordan den ble ødelagt.

Ctrl-S-fellen bak en overbevisende frysing

Når programvareflytkontroll er aktivert og de vanlige tegnene er tildelt, forteller Ctrl-S terminalen å slutte å sende utdata, og Ctrl-Q forteller den å fortsette. Sesjonen holder seg i live hele tiden, en enkelt Ctrl-Q er ofte hele reparasjonen, og ingenting vises i noen logg, og slik overlever denne frysingen så mange eskaleringer.

Inspiser de faktiske innstillingene i stedet for å anta dem. Start- og stopptegnene kan tildeles på nytt eller deaktiveres, og en terminal med flytkontroll av reagerer ikke på noen av dem.

Hvis tilstanden kommer tilbake, eller SSH selv stopper

En tilbakevendende dårlig tilstand peker på noe som endrer flaggene uten å gjenopprette dem, som en oppstartsfil, et innpakningsskript, en multiplekser som nullstiller feil vindu, eller en applikasjon som dør mens den holder rå modus. Legg til en betinget sjekk som rapporterer tilstanden i stedet for en betingelsesløs nullstilling, fordi en generell nullstilling skjuler årsaken og kan overstyre bevisste innstillinger.

Når vanlig SSH-trafikk også stopper, eller reparasjonen ikke endrer noe, slutter terminalen å være den mistenkte.

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

En fastlåsing som bare vises under store overføringer tyder på et MTU-problem på veien, mens en som også svelger enkelttastetrykk peker på veien eller serveren og ikke på pakkestørrelsen. Hold terminalbevisene atskilt fra nettverksbevisene, fordi en fungerende editor i en annen sesjon ikke er bevis for at den første terminalen noen gang var sunn.