vim fryser över SSH? Kontrollera stty innan du skyller på VPN:en

Sådana här sessioner hålls anslutna medan editorn startar, och sedan slutar skärmen att uppdateras trots att SSH-processen tydligt lever. Det går inte att skriva något, Ctrl-C verkar inte göra något, och den uppenbara slutsatsen är att VPN:en tappade något. Oftast är tunneln i ordning och den fjärran pseudoterminalen är i ett tillstånd som ingen avsåg, eftersom eko, kanonisk inmatning och flödeskontroll bor i terminalen och inte i nätet. Att ta reda på vilken av de tre som flyttade sig är ett jobb på två kommandon.

Frysningen bor i terminalen, inte i tunneln

En pseudoterminal bär mer än bytes. Den håller linjedisciplinflaggor som avgör om inmatning ekar, om läsningar väntar på en ny rad, om vissa tecken genererar signaler och om utdata kan stoppas av ett styrtecken. En interaktiv editor sätter den terminalen i råläge för hela tiden och förväntas återställa de tidigare inställningarna vid avslut. När återställningen inte sker är skalet du återvänder till inte skalet du lämnade, även om anslutningen aldrig bröts.

Jämför terminaler innan du drar någon slutsats. En andra session med samma editor bevisar att klienten och vägen klarar jobbet; den säger ingenting om terminalen vars flaggor är trasiga.

Läs inställningarna på terminalen som frös

Identifiera först enheten och läs sedan båda formerna av dess tillstånd. Den läsbara formen visar vad som är inställt, och maskinformen är den du kan mata tillbaka senare.

tty
stty -a
stty -g

Tre flagggrupper förklarar de flesta av dessa rapporter. Ekoinställningar avgör om tangenttryckningar alls syns, så en terminal med eko av verkar död medan skalet tar emot varje tecken. Kanoniskt läge avgör om ett program ser inmatning rad för rad, så en terminal som lämnats i kanoniskt läge får ett program i råläge att verka ignorera tangenter till Enter. Flödeskontrollinställningar avgör om terminalen lyder tecknen XON och XOFF, och den gruppen producerar den mest övertygande falska frysningen av de tre.

Registrera utdata innan du ändrar något, särskilt när sessionen bär egna tangentbindningar som någon är beroende av. Maskinformen är den säkraste registreringen, med förbehållet att den är implementeringsspecifik och bör återställas av samma sorts system som producerade den.

Reparera den terminalen, inte sessionen du skriver i

Standardreparationen återställer den friska profilen som manualsidan listar, och den påverkar bara en terminal. Om editorn fortfarande har osparat arbete i den terminalen, låt den vara tills arbetet är sparat.

Från ett annat skal, rikta in dig uttryckligen på den frysta enheten så att terminalen du arbetar i förblir orörd.

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

En tom skärm med en trasig visning är ett annat problem än bruten linjedisciplin, och reset-programmet hanterar det genom att skicka ut terminalinitieringssekvenser. Prova tillståndsreparationen först, eftersom den ändrar inställningar du kan granska, medan reset-sekvensen skriver om skärmen och inte förklarar något om hur den gick sönder.

Ctrl-S-fällan bakom en övertygande frysning

När programvaruflödeskontroll är aktiverad och de vanliga tecknen är tilldelade säger Ctrl-S till terminalen att sluta skicka utdata, och Ctrl-Q säger till den att fortsätta. Sessionen hålls levande hela tiden, ett enda Ctrl-Q är ofta hela reparationen, och ingenting visas i någon logg, och så överlever den här frysningen så många eskaleringar.

Granska de faktiska inställningarna i stället för att anta dem. Start- och stopptecknen kan tilldelas på nytt eller inaktiveras, och en terminal med flödeskontroll av reagerar inte på någon av dem.

Om tillståndet återkommer, eller SSH självt fastnar

Ett återkommande dåligt tillstånd pekar på något som ändrar flaggorna utan att återställa dem: en startfil, ett omslagsskript, en multiplexer som nollställer fel fönster eller ett program som dör medan det håller råläget. Lägg till en villkorad kontroll som rapporterar tillståndet i stället för en ovillkorlig nollställning, eftersom en generell nollställning döljer orsaken och kan skriva över avsiktliga inställningar.

När vanlig SSH-trafik också fastnar, eller reparationen inte ändrar något, slutar terminalen att vara den misstänkta.

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

En fastlåsning som bara dyker upp vid stora överföringar tyder på ett MTU-problem på vägen, medan en som också sväljer enstaka tangenttryckningar pekar på vägen eller servern och inte på paketstorleken. Håll terminalbevisen åtskilda från nätverksbevisen, eftersom en fungerande editor i en andra session inte är bevis för att den första terminalen någonsin var frisk.