¿vim se congela por SSH? Comprueba stty antes de culpar a la VPN

Sesiones como esta siguen conectadas mientras arranca el editor, y luego la pantalla deja de actualizarse aunque el proceso SSH está claramente vivo. Escribir no produce nada, Ctrl-C parece no hacer nada, y la conclusión obvia es que la VPN ha dejado caer algo. La mayoría de las veces el túnel está bien y el pseudo-terminal remoto está en un estado que nadie pretendía, porque el eco, la entrada canónica y el control de flujo viven en el terminal y no en la red. Averiguar cuál de los tres se movió es una tarea de dos comandos.

La congelación vive en el terminal, no en el túnel

Un pseudo-terminal lleva más que bytes. Contiene indicadores de disciplina de línea que deciden si la entrada se muestra, si las lecturas esperan una línea nueva, si ciertos caracteres generan señales y si la salida puede detenerse con un carácter de control. Un editor interactivo pone ese terminal en modo crudo durante toda la sesión y debería restaurar la configuración anterior al salir. Cuando la restauración no ocurre, el shell al que vuelves no es el shell que dejaste, aunque la conexión nunca se cayera.

Compara terminales antes de concluir nada. Una segunda sesión con el mismo editor demuestra que el cliente y la ruta pueden hacer el trabajo; no dice nada del terminal cuyos indicadores están rotos.

Lee la configuración en el terminal que se congeló

Identifica primero el dispositivo y luego lee las dos formas de su estado. La forma legible muestra qué está definido, y la forma de máquina es la que puedes volver a aplicar después.

tty
stty -a
stty -g

Tres grupos de indicadores explican la mayoría de estos informes. La configuración de eco decide si las pulsaciones aparecen siquiera, así que un terminal con el eco desactivado parece muerto mientras el shell recibe cada carácter. El modo canónico decide si un programa ve la entrada línea a línea, así que un terminal dejado en modo canónico hace que una aplicación en modo crudo parezca ignorar las teclas hasta Enter. La configuración de control de flujo decide si el terminal obedece los caracteres XON y XOFF, y ese grupo produce la congelación falsa más convincente de las tres.

Registra la salida antes de cambiar nada, sobre todo cuando la sesión lleva combinaciones de teclas personalizadas de las que alguien depende. La forma de máquina es el registro más seguro, con la advertencia de que depende de la implementación y debe restaurarla el mismo tipo de sistema que la produjo.

Repara ese terminal, no la sesión en la que escribes

La reparación estándar restaura el perfil sano que enumera la página del manual, y afecta solo a un terminal. Si el editor aún tiene trabajo sin guardar en ese terminal, déjalo en paz hasta que el trabajo esté guardado.

Desde otro shell, apunta explícitamente al dispositivo congelado para que el terminal en el que trabajas quede intacto.

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

Una pantalla en blanco con una visualización corrupta es un problema distinto de una disciplina de línea rota, y el programa reset lo aborda emitiendo secuencias de inicialización del terminal. Prueba primero la reparación del estado, porque cambia ajustes que puedes inspeccionar, mientras que la secuencia reset reescribe la pantalla y no explica nada sobre cómo se rompió.

La trampa de Ctrl-S detrás de una congelación convincente

Cuando el control de flujo por software está activado y los caracteres habituales están asignados, Ctrl-S le dice al terminal que deje de enviar salida y Ctrl-Q le dice que continúe. La sesión sigue viva todo el tiempo, un solo Ctrl-Q suele ser toda la reparación, y no aparece nada en ningún registro, y así es como esta congelación sobrevive a tantas escaladas.

Inspecciona la configuración real en lugar de suponerla. Los caracteres de inicio y parada pueden reasignarse o desactivarse, y un terminal con el control de flujo desactivado no reaccionará a ninguno de los dos.

Si el estado vuelve, o el propio SSH se atasca

Un estado malo recurrente apunta a algo que cambia los indicadores sin restaurarlos: un archivo de inicio, un script envoltorio, un multiplexor que reinicia la ventana equivocada o una aplicación que muere mientras mantiene el modo crudo. Añade una comprobación condicional que informe del estado en lugar de un reinicio incondicional, porque un reinicio general oculta la causa y puede pasar por encima de ajustes deliberados.

Cuando el tráfico SSH normal también se atasca, o la reparación no cambia nada, el terminal deja de ser el sospechoso.

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

Un atasco que solo aparece durante transferencias grandes sugiere un problema de MTU en la ruta, mientras que uno que también se traga pulsaciones individuales apunta a la ruta o al servidor y no al tamaño del paquete. Mantén las pruebas del terminal separadas de las pruebas de la red, porque un editor que funciona en una segunda sesión no es prueba de que el primer terminal haya estado sano alguna vez.