¿Hay alguna forma de evitar la congelación de tmux cuando se envía mucho texto al terminal?

En una sesión de tmux dentro de xterm, cuando un programa genera mucha salida (como una cat very_long_filesesión entera congelada por un tiempo. Incluso si presiono Ctrl-C, nada se interrumpe. Presumiblemente porque tmux está congelado y no reenvía Ctrl-C a el programa que genera la salida. ¿Hay alguna manera de evitar esto?

La solución correcta es mirar las opciones de c0- * a tmux para intentar limitar la velocidad de salida. La razón por la que este problema existe es debido a que los datos se envían al terminal más rápido de lo que puede mostrarlo, por lo que limitar la velocidad es la única forma.

Todavía tengo este problema en tmux 1.6-2 en Ubuntu 12.10. Una solución alternativa que he encontrado es desconectarse de la sesión (prefijo + d) y luego volver a adjuntar ( tmux attach, buen candidato para un alias de shell rápido). Parece que tmux en realidad responde bajo el capó --- puede confirmar que su proceso realmente se elimina inmediatamente con ctrl-c --- es solo el dibujo el que está bloqueando. Detatch funciona de inmediato, y cuando vuelva a conectar, el dibujo habrá saltado hasta el final.

Hasta donde yo sé, no hay forma de prevenirlo en las versiones actuales, pero algunos trabajos están en curso. Puede encontrar algunos parches en la lista de correo de tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Una buena palabra clave para buscar en la web es "control de flujo".

Desafortunadamente, las opciones c0- * para limitar la velocidad se han eliminado a partir de la versión 2.1 de tmux ( registro de cambios ). Hasta donde sé, la única forma de personalizar la limitación de velocidad es actualizar las variables que lo influyen en el código fuente (tmux.h):

" READ_SIZE es el tamaño máximo de datos para retener desde una pty (la marca de agua de evento alta). READ_BACKOFF es la cantidad de datos que se espera que se envíe a un tty antes de que las lecturas de pty se retrocedan. READ_TIME es cuánto tiempo retroceder antes de la siguiente lectura (en microsegundos) si un tty está por encima de READ_BACKOFF " .

Donde encontrará los valores predeterminados: (a partir de tmux v2.2):

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100

La respuesta https://superuser.com/a/589896/311481 funciona bien. Yo uso los siguientes valores:

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

Otro consejo: si usa ssh dentro de tmux, use mosh en su lugar: http://mosh.mit.edu/ Se comporta de manera más inteligente para mostrar la salida de los programas. Intenta mostrar el último estado de la pantalla colocando intermedios cuando es apropiado. Por lo tanto, tmux nunca se congelará si se genera mucha salida dentro de sus paneles con sesiones de mosh dentro.

A diferencia de SSH, el protocolo basado en UDP de mosh maneja la pérdida de paquetes con gracia y establece la velocidad de cuadros en función de las condiciones de la red. Mosh no llena los buffers de red, por lo que Control-C siempre trabaja para detener un proceso desbocado.

Debido a que el SSP [Protocolo de sincronización de estado que Mosh usa] funciona en la capa de objeto y puede controlar la velocidad de sincronización (en otras palabras, la velocidad de cuadros), no necesita enviar todos los bytes que recibe de la aplicación. Eso significa que Mosh puede regular las tramas para no llenar las memorias intermedias de la red, conservando la capacidad de respuesta de la conexión y asegurándose de que Control-C siempre funcione rápidamente. Los protocolos que deben enviar cada byte no pueden hacer esto.

Pruebe diferentes emuladores de terminal. En RedHat 6.5, konsole (KDE) no tiene el problema de congelación (tmux 2.3 y master); sin embargo, xterm y gnome-terminal experimentan una mala congelación.