Esiste un modo per impedire il congelamento di tmux quando viene inviato molto testo al terminale?

In una sessione di tmux all'interno di xterm quando un programma genera un sacco di output (come cat very_long_fileun'intera sessione congelata per un po '. Anche se premo Ctrl-C nulla viene interrotto. Presumibilmente perché tmux è congelato e non sta inoltrando Ctrl-C a il programma che genera l'output. Esiste un modo per impedirlo.

La soluzione corretta è guardare le opzioni c0- * su tmux per provare a limitare l'output. Il motivo per cui questo problema esiste è dovuto al fatto che i dati vengono inviati al terminale più velocemente di quanto possa visualizzarlo, quindi la limitazione della velocità è l'unico modo.

Ho ancora questo problema in tmux 1.6-2 su Ubuntu 12.10. Una soluzione alternativa che ho trovato è quella di staccare dalla sessione (prefisso + d) e quindi ricollegarlo ( tmux attach, buon candidato per un alias di shell veloce). Sembra che tmux sia effettivamente reattivo sotto il cofano --- puoi confermare che il tuo processo è effettivamente interrotto immediatamente con ctrl-c --- è solo il disegno che sta bloccando. Detatch funziona immediatamente e quando si ricollega, il disegno sarà saltato fino alla fine.

Per quanto ne so non c'è modo di impedirlo nelle versioni attuali, ma alcuni lavori sono in corso. Puoi trovare alcune patch nella mailing list di tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Una buona parola chiave per cercare nel web è "controllo del flusso".

Purtroppo le opzioni C0 * per limitazione della velocità sono stati rimossi a partire dal tmux versione 2.1 ( changelog ). Per quanto ne so, l'unico modo per personalizzare il limite di velocità è aggiornare le variabili che lo influenzano nel codice sorgente (tmux.h):

" READ_SIZE è la dimensione massima dei dati da conservare da un pty (la filigrana alta dell'evento). READ_BACKOFF è la quantità di dati in attesa di essere trasmessi a un tty prima che le letture di pty vengano annullate. READ_TIME è il tempo di cui eseguire il back-up prima che il lettura successiva (in microsecondi) se una tty è sopra READ_BACKOFF. "

Dove troverai le impostazioni predefinite: (a partire da tmux v2.2):

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

La risposta https://superuser.com/a/589896/311481 funziona bene. Uso i seguenti valori:

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

Un altro consiglio: se usi ssh in tmux, usa invece mosh: http://mosh.mit.edu/ Si comporta in modo più intelligente per visualizzare l'output dei programmi. Tenta di visualizzare gli stati intermedi che rilasciano l'ultimo schermo quando appropriato. Quindi tmux non si bloccherà mai se viene generato molto output nei suoi riquadri con sessioni mosh all'interno.

A differenza di SSH, il protocollo basato su UDP di mosh gestisce la perdita di pacchetti con grazia e imposta la frequenza dei fotogrammi in base alle condizioni della rete. Mosh non riempie i buffer di rete, quindi Control-C lavora sempre per fermare un processo in fuga.

Poiché SSP [State Synchronization Protocol che utilizza mosh] funziona a livello di oggetto e può controllare la velocità di sincronizzazione (in altre parole, la frequenza dei fotogrammi), non è necessario inviare tutti i byte che riceve dall'applicazione. Ciò significa che Mosh può regolare i frame in modo da non riempire i buffer di rete, mantenendo la reattività della connessione e assicurandosi che Control-C funzioni sempre rapidamente. I protocolli che devono inviare ogni byte non possono farlo.

Prova un emulatore di terminale diverso. Su RedHat 6.5, la konsole (KDE) non presenta il problema del congelamento (tmux 2.3 e master); tuttavia, xterm e gnome-terminal hanno entrambi un cattivo congelamento.