vim conxélase por SSH? Comproba stty antes de culpar a VPN

Sesións coma esta seguen conectadas mentres arrinca o editor, e despois a pantalla deixa de actualizarse aínda que o proceso SSH está claramente vivo. Escribir non produce nada, Ctrl-C parece non facer nada, e a conclusión obvia é que a VPN deixou caer algo. A maioría das veces o túnel está ben e o pseudo-terminal remoto está nun estado que ninguén pretendía, porque o eco, a entrada canónica e o control de fluxo viven no terminal e non na rede. Averiguar cal dos tres se moveu é un traballo de dous comandos.

A conxelación vive no terminal, non no túnel

Un pseudo-terminal leva máis que bytes. Contén indicadores de disciplina de liña que deciden se a entrada se mostra, se as lecturas esperan unha liña nova, se certos caracteres xeran sinais e se a saída se pode deter cun carácter de control. Un editor interactivo pon ese terminal en modo cru durante toda a sesión e debería restaurar a configuración anterior ao saír. Cando a restauración non ocorre, a shell á que volves non é a shell que deixaches, aínda que a conexión nunca se caese.

Compara terminais antes de concluír nada. Unha segunda sesión co mesmo editor demostra que o cliente e a ruta poden facer o traballo; non di nada do terminal cuxos indicadores están rotos.

Le a configuración no terminal que se conxelou

Identifica primeiro o dispositivo e despois le as dúas formas do seu estado. A forma lexible mostra que está definido, e a forma de máquina é a que podes volver aplicar despois.

tty
stty -a
stty -g

Tres grupos de indicadores explican a maioría destes informes. A configuración de eco decide se as pulsacións aparecen, así que un terminal co eco desactivado parece morto mentres a shell recibe cada carácter. O modo canónico decide se un programa ve a entrada liña a liña, así que un terminal deixado en modo canónico fai que unha aplicación en modo cru pareza ignorar as teclas ata Enter. A configuración de control de fluxo decide se o terminal obedece os caracteres XON e XOFF, e ese grupo produce a conxelación falsa máis convincente das tres.

Rexistra a saída antes de cambiar nada, sobre todo cando a sesión leva combinacións de teclas personalizadas das que alguén depende. A forma de máquina é o rexistro máis seguro, coa advertencia de que depende da implementación e debe restaurala o mesmo tipo de sistema que a produciu.

Repara ese terminal, non a sesión na que escribes

A reparación estándar restaura o perfil san que enumera a páxina do manual, e afecta só un terminal. Se o editor aínda ten traballo sen gardar nese terminal, déixao tranquilo ata que o traballo estea gardado.

Desde outra shell, apunta explicitamente ao dispositivo conxelado para que o terminal no que traballas quede intacto.

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

Unha pantalla en branco cunha visualización corrupta é un problema distinto dunha disciplina de liña rota, e o programa reset abórdano emitindo secuencias de inicialización do terminal. Proba primeiro a reparación do estado, porque cambia axustes que podes inspeccionar, mentres que a secuencia reset reescribe a pantalla e non explica nada sobre como se rompeu.

A trampa de Ctrl-S detrás dunha conxelación convincente

Cando o control de fluxo por software está activado e os caracteres habituais están asignados, Ctrl-S dille ao terminal que deixe de enviar saída e Ctrl-Q dille que continúe. A sesión segue viva todo o tempo, un só Ctrl-Q adoita ser toda a reparación, e non aparece nada en ningún rexistro, e así é como esta conxelación sobrevive a tantas escaladas.

Inspecciona a configuración real en lugar de supoñela. Os caracteres de inicio e parada poden reasignarse ou desactivarse, e un terminal co control de fluxo desactivado non reaccionará a ningún dos dous.

Se o estado volve, ou o propio SSH atasca

Un estado malo recorrente apunta a algo que cambia os indicadores sen restauralos: un ficheiro de inicio, un script envoltorio, un multiplexor que reinicia a ventá equivocada ou unha aplicación que morre mentres mantén o modo cru. Engade unha comprobación condicional que informe do estado en lugar dun reinicio incondicional, porque un reinicio xeral oculta a causa e pode pasar por riba de axustes deliberados.

Cando o tráfico SSH normal tamén atasca, ou a reparación non cambia nada, o terminal deixa de ser o sospeitoso.

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

Un atasco que só aparece durante transferencias grandes suxire un problema de MTU na ruta, mentres que un que tamén traga pulsacións individuais apunta á ruta ou ao servidor e non ao tamaño do paquete. Mantén as probas do terminal separadas das probas da rede, porque un editor que funciona nunha segunda sesión non é proba de que o primeiro terminal estivese san algunha vez.