vim friert über SSH ein? Prüfen Sie stty, bevor Sie das VPN beschuldigen

Solche Sitzungen bleiben verbunden, während der Editor startet, dann hört der Bildschirm auf, sich zu aktualisieren, obwohl der SSH-Prozess offensichtlich läuft. Tippen bewirkt nichts, Ctrl-C scheint nichts zu tun, und die naheliegende Schlussfolgerung ist, dass das VPN etwas fallen gelassen hat. Meistens ist der Tunnel in Ordnung und das entfernte Pseudoterminal in einem Zustand, den niemand beabsichtigt hat, weil Echo, kanonische Eingabe und Flusskontrolle im Terminal leben und nicht im Netzwerk. Welche der drei sich verschoben hat, herauszufinden, ist eine Aufgabe von zwei Befehlen.

Das Einfrieren lebt im Terminal, nicht im Tunnel

Ein Pseudoterminal trägt mehr als Bytes. Es hält Flags der Leitungsdisziplin, die entscheiden, ob Eingaben zurückgespiegelt werden, ob Lesezugriffe auf eine neue Zeile warten, ob bestimmte Zeichen Signale erzeugen und ob die Ausgabe durch ein Steuerzeichen gestoppt werden kann. Ein interaktiver Editor schaltet dieses Terminal für die Dauer in den Rohmodus und sollte beim Beenden die vorherigen Einstellungen wiederherstellen. Wenn die Wiederherstellung ausbleibt, ist die Shell, zu der Sie zurückkehren, nicht die Shell, die Sie verlassen haben, auch wenn die Verbindung nie abbrach.

Vergleichen Sie Terminals, bevor Sie Schlüsse ziehen. Eine zweite Sitzung mit demselben Editor beweist, dass Client und Pfad die Arbeit leisten können; sie sagt nichts über das Terminal aus, dessen Flags kaputt sind.

Lesen Sie die Einstellungen an dem Terminal, das eingefroren ist

Identifizieren Sie zuerst das Gerät und lesen Sie dann beide Formen seines Zustands. Die lesbare Form zeigt, was gesetzt ist, und die Maschinenform ist die, die Sie später zurückspielen können.

tty
stty -a
stty -g

Drei Flag-Gruppen erklären die meisten dieser Berichte. Echo-Einstellungen entscheiden, ob Tastendrücke überhaupt erscheinen, also wirkt ein Terminal mit ausgeschaltetem Echo tot, während die Shell jedes Zeichen empfängt. Der kanonische Modus entscheidet, ob ein Programm Eingaben Zeile für Zeile sieht, also lässt ein im kanonischen Modus belassenes Terminal eine Anwendung im Rohmodus so erscheinen, als ignorierte sie Tasten bis Enter. Flusskontroll-Einstellungen entscheiden, ob das Terminal die Zeichen XON und XOFF befolgt, und diese Gruppe erzeugt das überzeugendste falsche Einfrieren der drei.

Zeichnen Sie die Ausgabe auf, bevor Sie etwas ändern, besonders wenn die Sitzung eigene Tastenbelegungen trägt, auf die sich jemand verlässt. Die Maschinenform ist der sicherste Datensatz, mit der Einschränkung, dass sie implementierungsspezifisch ist und von derselben Art System wiederhergestellt werden sollte, die sie erzeugt hat.

Reparieren Sie genau dieses Terminal, nicht die Sitzung, in der Sie tippen

Die Standardreparatur stellt das gesunde Profil wieder her, das die Handbuchseite auflistet, und sie betrifft nur ein Terminal. Wenn der Editor in jenem Terminal noch ungespeicherte Arbeit hält, lassen Sie es in Ruhe, bis die Arbeit gespeichert ist.

Richten Sie sich von einer anderen Shell aus ausdrücklich an das eingefrorene Gerät, damit das Terminal, in dem Sie arbeiten, unberührt bleibt.

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

Ein leerer Bildschirm mit beschädigter Anzeige ist ein anderes Problem als eine kaputte Leitungsdisziplin, und das Programm reset behebt es, indem es Initialisierungssequenzen für das Terminal ausgibt. Versuchen Sie zuerst die Zustandsreparatur, weil sie Einstellungen ändert, die Sie prüfen können, während die reset-Sequenz den Bildschirm neu schreibt und nichts darüber erklärt, wie er kaputtging.

Die Ctrl-S-Falle hinter einem überzeugenden Einfrieren

Wenn die Software-Flusskontrolle aktiviert ist und die üblichen Zeichen zugewiesen sind, sagt Ctrl-S dem Terminal, es solle aufhören, Ausgabe zu senden, und Ctrl-Q sagt ihm, es solle fortfahren. Die Sitzung bleibt durchweg am Leben, ein einziges Ctrl-Q ist oft die ganze Reparatur, und in keinem Protokoll erscheint etwas, und so übersteht dieses Einfrieren so viele Eskalationen.

Prüfen Sie die tatsächlichen Einstellungen, statt sie anzunehmen. Die Start- und Stoppzeichen können neu zugewiesen oder deaktiviert werden, und ein Terminal mit ausgeschalteter Flusskontrolle reagiert auf keines von beiden.

Wenn der Zustand zurückkehrt oder SSH selbst stockt

Ein wiederkehrender schlechter Zustand deutet auf etwas hin, das die Flags ändert, ohne sie wiederherzustellen: eine Startdatei, ein Wrapper-Skript, ein Multiplexer, der das falsche Fenster zurücksetzt, oder eine Anwendung, die stirbt, während sie den Rohmodus hält. Fügen Sie eine bedingte Prüfung hinzu, die den Zustand meldet, statt eines bedingungslosen Zurücksetzens, denn ein pauschales Zurücksetzen verbirgt die Ursache und kann bewusste Einstellungen überschreiben.

Wenn auch gewöhnlicher SSH-Verkehr stockt oder die Reparatur nichts ändert, hört das Terminal auf, der Verdächtige zu sein.

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

Ein Stocken, das nur bei großen Übertragungen auftritt, deutet auf ein MTU-Problem auf dem Pfad hin, während eines, das auch einzelne Tastendrücke verschluckt, auf den Pfad oder den Server zeigt und nicht auf die Paketgröße. Halten Sie die Terminal-Beweise getrennt von den Netzwerk-Beweisen, denn ein funktionierender Editor in einer zweiten Sitzung ist kein Beweis dafür, dass das erste Terminal je gesund war.