vim bevriest via SSH? Controleer stty voordat je de VPN de schuld geeft

Sessies zoals deze blijven verbonden terwijl de editor start, en dan stopt het scherm met vernieuwen terwijl het SSH-proces duidelijk leeft. Typen levert niets op, Ctrl-C lijkt niets te doen, en de voor de hand liggende conclusie is dat de VPN iets heeft laten vallen. Meestal is de tunnel in orde en verkeert de externe pseudoterminal in een toestand die niemand bedoelde, omdat echo, canonieke invoer en flowbeheer in de terminal leven en niet in het netwerk. Uitzoeken welke van die drie verschoof is een klus van twee opdrachten.

De bevriezing zit in de terminal, niet in de tunnel

Een pseudoterminal draagt meer dan bytes. Hij houdt regeltuchtvlaggen die bepalen of invoer wordt teruggespiegeld, of leesacties op een nieuwe regel wachten, of bepaalde tekens signalen opwekken en of uitvoer door een stuurteken kan worden gestopt. Een interactieve editor zet die terminal voor de duur in de ruwe modus en hoort bij het afsluiten de vorige instellingen te herstellen. Als het herstel niet gebeurt, is de shell waar je naar terugkeert niet de shell die je verliet, ook al is de verbinding nooit verbroken.

Vergelijk terminals voordat je iets concludeert. Een tweede sessie met dezelfde editor bewijst dat de client en het pad het werk aankunnen; over de terminal waarvan de vlaggen kapot zijn zegt het niets.

Lees de instellingen op de terminal die bevroor

Identificeer eerst het apparaat en lees dan beide vormen van zijn toestand. De leesbare vorm laat zien wat er is ingesteld, en de machinevorm is degene die je later kunt terugvoeren.

tty
stty -a
stty -g

Drie vlaggroepen verklaren de meeste van deze rapporten. Echo-instellingen bepalen of toetsaanslagen überhaupt verschijnen, dus een terminal met echo uit lijkt dood terwijl de shell elk teken ontvangt. Canonieke modus bepaalt of een programma invoer regel voor regel ziet, dus een terminal die in canonieke modus is achtergelaten laat een toepassing in ruwe modus lijken of hij toetsen tot Enter negeert. Flowbeheer-instellingen bepalen of de terminal de tekens XON en XOFF gehoorzaamt, en die groep levert de overtuigendste nep-bevriezing van de drie.

Leg de uitvoer vast voordat je iets verandert, vooral wanneer de sessie eigen toetsenbindingen draagt waar iemand van afhankelijk is. De machinevorm is de veiligste registratie, met de kanttekening dat hij implementatieafhankelijk is en hersteld moet worden door hetzelfde soort systeem dat hem heeft gemaakt.

Repareer die ene terminal, niet de sessie waarin je typt

De standaardreparatie herstelt het gezonde profiel dat de manpagina vermeldt, en ze raakt maar één terminal. Als de editor nog niet-opgeslagen werk in die terminal heeft, laat hem dan met rust tot het werk is opgeslagen.

Vanuit een andere shell richt je je expliciet op het bevroren apparaat, zodat de terminal waarin je werkt onaangeroerd blijft.

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

Een leeg scherm met een beschadigde weergave is een ander probleem dan een kapotte regeltucht, en het reset-programma pakt dat aan door terminalinitialisatiesequenties uit te sturen. Probeer eerst de toestandsreparatie, want die verandert instellingen die je kunt inspecteren, terwijl de reset-sequentie het scherm herschrijft en niets uitlegt over hoe het brak.

De Ctrl-S-valkuil achter een overtuigende bevriezing

Wanneer softwarematige flowbeheer is ingeschakeld en de gebruikelijke tekens zijn toegewezen, zegt Ctrl-S tegen de terminal dat hij moet stoppen met uitvoer sturen en zegt Ctrl-Q dat hij moet doorgaan. De sessie blijft de hele tijd in leven, een enkele Ctrl-Q is vaak de hele reparatie, en er verschijnt niets in enig logboek, en zo overleeft deze bevriezing zoveel escalaties.

Inspecteer de werkelijke instellingen in plaats van ze aan te nemen. De start- en stottekens kunnen opnieuw worden toegewezen of uitgeschakeld, en een terminal met flowbeheer uit reageert op geen van beide.

Als de toestand terugkeert, of SSH zelf vastloopt

Een terugkerende slechte toestand wijst op iets dat de vlaggen verandert zonder ze te herstellen: een opstartbestand, een wrapperscript, een multiplexer die het verkeerde venster reset, of een toepassing die sterft terwijl hij de ruwe modus vasthoudt. Voeg een voorwaardelijke controle toe die de toestand meldt in plaats van een onvoorwaardelijke reset, want een algemene reset verbergt de oorzaak en kan bewuste instellingen overschrijven.

Wanneer ook gewoon SSH-verkeer vastloopt, of de reparatie verandert niets, houdt de terminal op de verdachte te zijn.

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

Een vastloper die alleen bij grote overdrachten optreedt wijst op een MTU-probleem op het pad, terwijl een die ook losse toetsaanslagen doorslikt op het pad of de server wijst en niet op de pakketgrootte. Houd de terminalbewijzen gescheiden van de netwerkbewijzen, want een werkende editor in een tweede sessie is geen bewijs dat de eerste terminal ooit gezond was.