In a tmux session inside xterm when a programs generates lots of ouput (like a cat very_long_file the whole session in frozen for a while. Even if I press Ctrl-C nothing is interrupted. Presumably because tmux is frozen and it's not forwarding the Ctrl-C to the program generating the output. Is there any way to prevent this.

  • The problem is that the program wrote its output to standard out far faster than your terminal could display it. When you hit Ctrl-C, the process is indeed killed, but your terminal continues to print the buffered output.
    – chepner
    Commented Apr 30, 2012 at 21:16
  • 1
    Horizontally splitting tmux panes (i.e. C-b %) is much more sensitive to this issue than full panes or vertically split panes. Also, running C-b d and reattaching will "unfreeze" the program, although only temporarily. There isn't really a solution unless you're willing to dig into tmux configurations. Commented Aug 5, 2014 at 22:38

6 Answers 6


The correct solution is to look at the c0-* options to tmux to try and rate-limit the output. The reason this problem exists at all is due to data being sent to the terminal faster than it can display it, so rate-limiting is the only way.

  • c0-change-trigger and c0-change-interval seem to solve the problem. The default settings are enough for me. Commented May 2, 2013 at 4:58
  • setw -g c0-change-interval 100 and setw -g c0-change-trigger 250 doesn't make any difference for me. I'm using tmux-1.8. Did I do something wrong?
    – solotim
    Commented Aug 20, 2013 at 10:45
  • @solotim Works on my tmux 1.9a, however I added set-window-option -g ... into my .tmux.conf.
    – polym
    Commented Jul 25, 2014 at 14:32
  • 7
    Apparently, these have been removed in tmux 2.2. :( Commented Aug 3, 2017 at 14:13
  • 3
    This answer lacks the exact steps or commands to solve the issue.
    – oliora
    Commented Nov 19, 2020 at 16:40

I still have this problem in tmux 1.6-2 on Ubuntu 12.10. One workaround that I've found is to detatch from the session (prefix+d) and then reattach (tmux attach, good candidate for a quick shell alias). It looks like tmux is actually responsive under the hood---you can confirm that your process is actually killed immediately with ctrl-c---it's just the drawing that's blocking. Detatch works immediately, and when you reattach, the drawing will have skipped to the end.

  • Good workaround. It seems that in fact everything works, even switching between splits, it just does not get drawn.
    – jmiserez
    Commented Oct 20, 2013 at 12:51
  • 1
    This should be tmux attach, right?
    – Pandu
    Commented Mar 6, 2014 at 20:55
  • Oops, you're right. Fixed. Commented Mar 7, 2014 at 21:11
  • 2
    And if you can't detach, e.g. not sure of the macro, just open a new terminal window and tmux attach.
    – mahemoff
    Commented Apr 4, 2014 at 22:51

As far as I know there is no way to prevent it in current releases but some work is ongoing. You can find some patches on tmux's mailing list http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689.

A good keyword to search the web is "flow control".

  • 2
    why the patch is not validated in the main branch? this issue is the most important reason I still use gnu_screen.
    – solotim
    Commented Aug 15, 2012 at 6:51

The answer https://superuser.com/a/589896/311481 works fine. I use the following values:

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

Another tip: if you use ssh within tmux, use mosh instead: http://mosh.mit.edu/ It behaves smarter as to displaying programs' output. It tries to display the last screen state dropping intermediates when appropriate. So tmux will never freeze if lots of output is generated within its panes with mosh sessions inside.

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.


Unfortunately the c0-* options for rate limiting have been removed as of tmux version 2.1 (changelog). As far as I know, the only way to customize rate limiting is to update the variables influencing it in the source code (tmux.h):

"READ_SIZE is the maximum size of data to hold from a pty (the event high watermark). READ_BACKOFF is the amount of data waiting to be output to a tty before pty reads will be backed off. READ_TIME is how long to back off before the next read (in microseconds) if a tty is above READ_BACKOFF."

Where you will find the defaults: (as of tmux v2.2):

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100
  • 1
    In tmux v2.3 the indicated variables do not exist. Commented Jan 11, 2017 at 15:36

Try different terminal emulator. On RedHat 6.5, the konsole (KDE) does not have the freezing issue (tmux 2.3 and master); however, xterm and gnome-terminal both experience bad freezing.

  • tmux 2.2 however works fine without freezing issue on all three terminal emulators.
    – kko
    Commented Feb 1, 2017 at 6:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .