27

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/[email protected]/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.
3
  • 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, 2012 at 16:21
  • @Peter.O Just simply input "yes" then press Enter, your tmux is doomed.
    – solotim
    Dec 25, 2012 at 6:43
  • Possible duplicate
    – Pablo A
    Oct 15, 2021 at 19:31

6 Answers 6

11

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.

4
  • This should be the accepted solution, because it works.
    – polym
    Jul 25, 2014 at 14:33
  • 2
    E.g. setw -g c0-change-trigger 10 setw -g c0-change-interval 250 >> ~/.tmux.conf Oct 1, 2015 at 14:54
  • 3
    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, 2016 at 4:44
  • 3
    Since Tmux 2.1, these options no longer exist according to raw.githubusercontent.com/tmux/tmux/2.6/CHANGES The c0-* options for rate-limiting have been removed. Instead, a backoff approach is used.
    – megar
    Dec 19, 2017 at 9:49
9

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.

1
4

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.

4

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.

1
  • Strangely enough, this happens when I'm working locally. mosh looks pretty neat, though.
    – Snowball
    Nov 13, 2012 at 6:26
1

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.

1
  • 1
    They appear to be trying to fix this rather than using the workaround, so newer versions should get even better about the output. github.com/tmux/tmux/issues/849
    – dragon788
    Apr 13, 2017 at 18:32
1

I fought with this for a few weeks. I finally compiled from scratch, ncurses 6.4, libevent 2.1.12, and tmux 3.3a. Signal handling works as expected.

Avoid Ubuntu tmux 3.2a and take a few minutes and build from source.

If for some reason you can't compile from source try the following in your .tmux.conf: bind-key -n C-c send-keys C-z "kill -9 %1" Enter

It will map CTRL-C into a macro of CTRL-Z (background process) and kill the background process with SIGKILL.

You must log in to answer this question.

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