vim se fige via SSH ? Vérifiez stty avant d'accuser le VPN

Des sessions comme celle-ci restent connectées pendant que l'éditeur démarre, puis l'écran cesse de se rafraîchir alors que le processus SSH est clairement vivant. La frappe ne produit rien, Ctrl-C semble ne rien faire, et la conclusion évidente est que le VPN a laissé tomber quelque chose. La plupart du temps, le tunnel est intact et le pseudo-terminal distant est dans un état que personne n'a voulu, parce que l'écho, l'entrée canonique et le contrôle de flux vivent dans le terminal et non dans le réseau. Déterminer lequel de ces trois a bougé est un travail de deux commandes.

Le figement vit dans le terminal, pas dans le tunnel

Un pseudo-terminal transporte plus que des octets. Il porte des indicateurs de discipline de ligne qui décident si l'entrée est réaffichée, si les lectures attendent un saut de ligne, si certains caractères génèrent des signaux et si la sortie peut être arrêtée par un caractère de contrôle. Un éditeur interactif bascule ce terminal en mode brut pour toute la durée et devrait restaurer les réglages précédents en sortant. Quand la restauration n'a pas lieu, le shell auquel vous revenez n'est pas celui que vous avez quitté, même si la connexion n'a jamais été coupée.

Comparez les terminaux avant de conclure quoi que ce soit. Une seconde session avec le même éditeur prouve que le client et le chemin peuvent faire le travail ; elle ne dit rien du terminal dont les indicateurs sont cassés.

Lisez les réglages sur le terminal qui s'est figé

Identifiez d'abord le périphérique, puis lisez les deux formes de son état. La forme lisible montre ce qui est réglé, et la forme machine est celle que vous pourrez réinjecter plus tard.

tty
stty -a
stty -g

Trois groupes d'indicateurs expliquent la plupart de ces rapports. Les réglages d'écho décident si les frappes apparaissent du tout, donc un terminal dont l'écho est désactivé semble mort alors que le shell reçoit chaque caractère. Le mode canonique décide si un programme voit l'entrée ligne par ligne, donc un terminal laissé en mode canonique fait qu'une application en mode brut semble ignorer les touches jusqu'à Entrée. Les réglages de contrôle de flux décident si le terminal obéit aux caractères XON et XOFF, et ce groupe produit le faux figement le plus convaincant des trois.

Enregistrez la sortie avant de changer quoi que ce soit, surtout quand la session porte des raccourcis personnalisés dont quelqu'un dépend. La forme machine est l'enregistrement le plus sûr, avec la réserve qu'elle dépend de l'implémentation et qu'elle devrait être restaurée par le même type de système qui l'a produite.

Réparez ce terminal-là, pas la session dans laquelle vous tapez

La réparation standard restaure le profil sain que liste la page de manuel, et elle n'affecte qu'un terminal. Si l'éditeur détient encore du travail non enregistré dans ce terminal, laissez-le tranquille jusqu'à ce que le travail soit enregistré.

Depuis un autre shell, ciblez explicitement le périphérique figé pour que le terminal dans lequel vous travaillez reste intact.

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

Un écran vide avec un affichage corrompu est un problème distinct d'une discipline de ligne cassée, et le programme reset y répond en émettant des séquences d'initialisation du terminal. Essayez d'abord la réparation d'état, car elle modifie des réglages que vous pouvez inspecter, tandis que la séquence reset réécrit l'écran et n'explique rien de la façon dont il s'est cassé.

Le piège Ctrl-S derrière un figement convaincant

Quand le contrôle de flux logiciel est activé et que les caractères habituels sont attribués, Ctrl-S dit au terminal d'arrêter d'envoyer de la sortie et Ctrl-Q lui dit de reprendre. La session reste vivante tout du long, un seul Ctrl-Q suffit souvent à toute la réparation, et rien n'apparaît dans aucun journal, et c'est ainsi que ce figement survit à tant d'escalades.

Inspectez les réglages réels au lieu de les supposer. Les caractères de départ et d'arrêt peuvent être réattribués ou désactivés, et un terminal dont le contrôle de flux est désactivé ne réagira à ni l'un ni l'autre.

Si l'état revient, ou si SSH lui-même se bloque

Un mauvais état récurrent pointe vers quelque chose qui change les indicateurs sans les restaurer : un fichier de démarrage, un script enveloppe, un multiplexeur qui réinitialise la mauvaise fenêtre ou une application qui meurt en tenant le mode brut. Ajoutez une vérification conditionnelle qui signale l'état au lieu d'une réinitialisation inconditionnelle, car une réinitialisation générale masque la cause et peut écraser des réglages délibérés.

Quand le trafic SSH ordinaire se bloque aussi, ou que la réparation ne change rien, le terminal cesse d'être le suspect.

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

Un blocage qui n'apparaît que pendant les gros transferts suggère un problème de MTU sur le chemin, tandis qu'un blocage qui avale aussi des frappes isolées désigne le chemin ou le serveur et non la taille des paquets. Gardez les preuves du terminal séparées des preuves du réseau, car un éditeur qui fonctionne dans une seconde session ne prouve pas que le premier terminal ait jamais été sain.