Existe alguma maneira de impedir o congelamento do tmux quando muito texto é enviado para o terminal?

Em uma sessão tmux no xterm, quando um programa gera muita saída (como cat very_long_filea sessão inteira congelada por um tempo. Mesmo se eu pressionar Ctrl-C, nada é interrompido. Provavelmente porque o tmux está congelado e não está encaminhando o Ctrl-C para o programa que gera a saída.Existe alguma maneira de evitar isso.

A solução correta é examinar as opções c0- * no tmux para tentar limitar a taxa de saída. A razão pela qual esse problema existe é o fato de os dados serem enviados para o terminal mais rapidamente do que podem ser exibidos, portanto, a limitação da taxa é a única maneira.

Eu ainda tenho esse problema no tmux 1.6-2 no Ubuntu 12.10. Uma solução alternativa que encontrei é desanexar da sessão (prefixo + d) e reconectar ( tmux attachbom candidato a um alias de shell rápido). Parece que o tmux é realmente responsivo sob o capô - você pode confirmar que seu processo é realmente eliminado imediatamente com ctrl-c - é apenas o desenho que está bloqueando. A remoção funciona imediatamente e, quando você reconecta, o desenho pulou para o final.

Tanto quanto sei, não há como evitá-lo nos lançamentos atuais, mas algum trabalho está em andamento. Você pode encontrar alguns patches na lista de discussão do tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Uma boa palavra-chave para pesquisar na web é "controle de fluxo".

Infelizmente, as opções c0- * para limitação de taxa foram removidas a partir da versão 2.1 do tmux ( changelog ). Até onde eu sei, a única maneira de personalizar o limite de taxa é atualizar as variáveis ​​que o influenciam no código-fonte (tmux.h):

" READ_SIZE é o tamanho máximo de dados a serem retidos de um pty (a marca d'água alta do evento). READ_BACKOFF é a quantidade de dados que aguardam a saída de um tty antes que as leituras do pty sejam recuadas. READ_TIME é o tempo de recuo antes do próxima leitura (em microssegundos) se um tty estiver acima de READ_BACKOFF. "

Onde você encontrará os padrões: (a partir do tmux v2.2):

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

A resposta https://superuser.com/a/589896/311481 funciona bem. Eu uso os seguintes valores:

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

Outra dica: se você usar o ssh no tmux, use o mosh: http://mosh.mit.edu/ Ele se comporta de maneira mais inteligente quanto à exibição dos resultados dos programas. Ele tenta exibir o último estado da tela eliminando intermediários quando apropriado. Portanto, o tmux nunca congelará se muita saída for gerada dentro de seus painéis com sessões mosh dentro.

Ao contrário do SSH, o protocolo baseado em UDP da mosh lida com a perda de pacotes normalmente e define a taxa de quadros com base nas condições da rede. O Mosh não preenche os buffers da rede; portanto, o Control-C sempre trabalha para interromper um processo descontrolado.

Como o SSP [Protocolo de Sincronização de Estado que o mosh usa] funciona na camada de objetos e pode controlar a taxa de sincronização (em outras palavras, a taxa de quadros), ele não precisa enviar todos os bytes recebidos do aplicativo. Isso significa que o Mosh pode regular os quadros para não preencher os buffers da rede, mantendo a capacidade de resposta da conexão e garantindo que o Control-C sempre funcione rapidamente. Os protocolos que devem enviar todos os bytes não podem fazer isso.

Tente emulador de terminal diferente. No RedHat 6.5, o konsole (KDE) não possui o problema de congelamento (tmux 2.3 e master); no entanto, o xterm e o gnome-terminal experimentam um congelamento ruim.