vim si blocca via SSH? Controlla stty prima di dare la colpa alla VPN

Sessioni come questa restano connesse mentre l'editor parte, poi lo schermo smette di aggiornarsi anche se il processo SSH è chiaramente vivo. Digitare non produce nulla, Ctrl-C sembra non fare nulla, e la conclusione ovvia è che la VPN abbia lasciato cadere qualcosa. Il più delle volte il tunnel è a posto e il pseudo-terminale remoto è in uno stato che nessuno intendeva, perché l'eco, l'input canonico e il controllo di flusso vivono nel terminale e non nella rete. Scoprire quale dei tre si è spostato è un lavoro da due comandi.

Il blocco vive nel terminale, non nel tunnel

Un pseudo-terminale trasporta più che byte. Contiene flag di disciplina di linea che decidono se l'input viene riecheggiato, se le letture aspettano un ritorno a capo, se certi caratteri generano segnali e se l'output può essere fermato da un carattere di controllo. Un editor interattivo mette quel terminale in modalità raw per tutta la durata e dovrebbe ripristinare le impostazioni precedenti all'uscita. Quando il ripristino non avviene, la shell a cui torni non è quella che hai lasciato, anche se la connessione non è mai caduta.

Confronta i terminali prima di concludere qualsiasi cosa. Una seconda sessione con lo stesso editor dimostra che il client e il percorso possono fare il lavoro; non dice nulla del terminale i cui flag sono rotti.

Leggi le impostazioni sul terminale che si è bloccato

Identifica prima il dispositivo, poi leggi entrambe le forme del suo stato. La forma leggibile mostra cosa è impostato, e la forma macchina è quella che puoi reinserire più tardi.

tty
stty -a
stty -g

Tre gruppi di flag spiegano la maggior parte di questi rapporti. Le impostazioni di eco decidono se le battute appaiono del tutto, quindi un terminale con l'eco disattivato sembra morto mentre la shell riceve ogni carattere. La modalità canonica decide se un programma vede l'input riga per riga, quindi un terminale lasciato in modalità canonica fa sembrare che un'applicazione in modalità raw ignori i tasti fino a Invio. Le impostazioni di controllo di flusso decidono se il terminale obbedisce ai caratteri XON e XOFF, e quel gruppo produce il falso blocco più convincente dei tre.

Registra l'output prima di cambiare qualsiasi cosa, soprattutto quando la sessione porta combinazioni di tasti personalizzate su cui qualcuno conta. La forma macchina è il record più sicuro, con l'avvertenza che dipende dall'implementazione e dovrebbe essere ripristinata dallo stesso tipo di sistema che l'ha prodotta.

Ripara quel terminale, non la sessione in cui stai digitando

La riparazione standard ripristina il profilo sano elencato dalla pagina di manuale, e colpisce un solo terminale. Se l'editor tiene ancora lavoro non salvato in quel terminale, lascialo stare finché il lavoro non è salvato.

Da un'altra shell, punta esplicitamente al dispositivo bloccato così il terminale in cui lavori resta intatto.

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

Uno schermo vuoto con una visualizzazione corrotta è un problema diverso da una disciplina di linea rotta, e il programma reset lo affronta emettendo sequenze di inizializzazione del terminale. Prova prima la riparazione dello stato, perché cambia impostazioni che puoi ispezionare, mentre la sequenza reset riscrive lo schermo e non spiega nulla di come si sia rotto.

La trappola di Ctrl-S dietro un blocco convincente

Quando il controllo di flusso software è attivo e i caratteri usuali sono assegnati, Ctrl-S dice al terminale di smettere di inviare output e Ctrl-Q gli dice di riprendere. La sessione resta viva per tutto il tempo, un solo Ctrl-Q è spesso tutta la riparazione, e non appare nulla in nessun log, ed è così che questo blocco sopravvive a tante escalation.

Ispeziona le impostazioni reali invece di presumere. I caratteri di avvio e arresto possono essere riassegnati o disattivati, e un terminale con il controllo di flusso disattivato non reagirà a nessuno dei due.

Se lo stato torna, o SSH stesso si blocca

Uno stato guasto ricorrente indica qualcosa che cambia i flag senza ripristinarli: un file di avvio, uno script wrapper, un multiplexer che resetta la finestra sbagliata o un'applicazione che muore tenendo la modalità raw. Aggiungi un controllo condizionale che riporti lo stato invece di un reset incondizionato, perché un reset generalizzato nasconde la causa e può sovrascrivere impostazioni deliberate.

Quando anche il traffico SSH ordinario si blocca, o la riparazione non cambia nulla, il terminale smette di essere il sospetto.

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

Un blocco che appare solo durante trasferimenti grandi suggerisce un problema di MTU sul percorso, mentre uno che inghiotte anche singole battute punta al percorso o al server e non alla dimensione dei pacchetti. Tieni le prove del terminale separate dalle prove della rete, perché un editor che funziona in una seconda sessione non è prova che il primo terminale sia mai stato sano.