Em uma sessão tmux dentro do xterm quando um programa gera muita saída (como cat very_long_file a sessão inteira em congelada por um tempo. Mesmo se eu pressionar Ctrl-C nada é interrompido. Presumivelmente 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.
Eu ainda tenho esse problema no tmux 1.6-2 no Ubuntu 12.10. Uma solução que eu encontrei é para separar da sessão (prefixo + d) e, em seguida, reconectar ( tmux attach , bom candidato para um alias de shell rápido). Parece que o tmux é realmente responsivo sob o capô --- você pode confirmar que o seu processo é realmente morto imediatamente com ctrl-c --- é apenas o desenho que está bloqueando. Detatch funciona imediatamente, e quando você reconecta, o desenho terá pulado para o final.
Até onde sei, não há como impedir isso nos lançamentos atuais, mas algum trabalho está em andamento. Você pode encontrar alguns patches na lista de discussão do tmux link .
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 do tmux versão 2.1 ( changelog ). Até onde eu sei, a única maneira de personalizar a limitação de taxa é atualizar as variáveis que a influenciam no código-fonte (tmux.h):
" READ_SIZE é o tamanho máximo dos dados a serem mantidos de uma pty (a marca d'água alta do evento). READ_BACKOFF é a quantidade de dados esperando para ser enviada para um tty antes que as leituras de pty sejam recuperadas. READ_TIME é como longo para recuar antes da 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 link 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 dentro do tmux, use mosh ao invés de: link Ele se comporta de maneira mais inteligente ao exibir a saída dos programas. Ele tenta exibir o último estado da tela soltando intermediários quando apropriado. Então o tmux nunca irá congelar se muitos outputs forem gerados dentro de seus painéis com mosh sessions dentro.
Unlike SSH, mosh's UDP-based protocol handles packet loss gracefully, and sets the frame rate based on network conditions. Mosh doesn't fill up network buffers, so Control-C always works to halt a runaway process.
Because SSP [State Synchronization Protocol that mosh uses] works at the object layer and can control the rate of synchronization (in other words, the frame rate), it does not need to send every byte it receives from the application. That means Mosh can regulate the frames so as not to fill up network buffers, retaining the responsiveness of the connection and making sure Control-C always works quickly. Protocols that must send every byte can't do this.
Experimente um 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 apresentam um congelamento ruim.
Tags tmux