Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I run a command with a lot of output in tmux, but decide to cancel it with Ctrl-C, there's a 10-15 second lag before it stops. However, if I do the same thing outside of tmux, it stops immediately. Why is this, and is it fixable?

In practice, this issue comes up when I'm doing grep -R on a large directory and my search isn't constrained enough. A workaround would be to pipe the result to wc first to make sure the output isn't too long, but that's just another step I'd like to avoid.


Notes:

  • This has the same behavior in Gnome Terminal, uxterm, st, and a plain virtual terminal (e.g., ctrl-alt-f2), but the delay is less in the plain virtual terminal.
  • I'm not the only one: http://www.mail-archive.com/tmux-users@lists.sourceforge.net/msg01569.html
  • The delay is longer if my terminal window is larger. For a fullscreen terminal, it takes about 15 seconds to stop grep -R (no other arguments) in a cluttered home directory. For a 80×25 character terminal, it stops almost immediately.
share|improve this question
    
I don't notice any discernable difference. I've tried grep -R "a" ~/ (not writing to file) ... and yes | nl | cut -f1 | head -9999999 > ~/file then cat ~/file . – Peter.O Aug 2 '12 at 16:21
    
@Peter.O Just simply input "yes" then press Enter, your tmux is doomed. – solotim Dec 25 '12 at 6:43

tmux now has the following options:

c0-change-interval interval
c0-change-trigger trigger

You can set values for these, which will make ^C and friends easier to type. See man tmux:

These two options configure a simple form of rate limiting for a pane. If tmux sees more than trigger C0 sequences that modify the screen (for example, carriage returns, linefeeds or backspaces) in one millisecond, it will stop updating the pane immediately and instead redraw it entirely every interval milliseconds. This helps to prevent fast output (such as yes(1)) overwhelming the terminal. The default is a trigger of 250 and an interval of 100. A trigger of zero disables the rate limiting.

share|improve this answer
    
This should be the accepted solution, because it works. – polym Jul 25 '14 at 14:33
1  
E.g. setw -g c0-change-trigger 10 setw -g c0-change-interval 250 >> ~/.tmux.conf – DmitrySandalov Oct 1 '15 at 14:54
    
I tried these on tmux 2.3 and they weren't recognized. It becomes totally unusable when commands spew lots of output. – ijt Jun 29 at 4:44

You can always issue kill-pane command from within the session. If the terminal text looks like garbage renaming the window and/or issuing reset should fix it.

share|improve this answer

Since tmux is inserting itself between the cat process and your terminal, it needs to read the output from cat, write it to the terminal , and at the same time read your input from the terminal (the ^C) and send it to the shell to interrupt the command. I'm not sure exactly what causes the delay, but it's something about how tmux buffers I/O between you and the shell that runs in tmux.

share|improve this answer

Assuming you are using ssh over a low-latency connection, have you tried using mosh? Among other very nice things like input prediction as well as surviving disconnects and even a changing IP on the client side, it also specifically improves the reaction time when using Ctrl-C (by only updating the terminal contents periodically instead of sending the whole stream).

You can use tmux within mosh without any problems.

share|improve this answer
    
Strangely enough, this happens when I'm working locally. mosh looks pretty neat, though. – Snowball Nov 13 '12 at 6:26

I was having this problem with tmux 2.3. I tried setting the c0-change-interval and c0-change-trigger options as described above but they are no longer available. Here is the git change with the new attempted solution: https://github.com/tmux/tmux/commit/3f4ee98162cd5bb7000f93fec0e631e123b1281d

Reverting to tmux 1.8 fixed the problem for me without having to set any options.

share|improve this answer

You must log in to answer this question.

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