tmux slow to interrupt process with Ctrl-C

25

6

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.

Snowball

Posted 2012-08-02T15:38:14.913

Reputation: 483

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 – 2012-08-02T16:21:59.197

@Peter.O Just simply input "yes" then press Enter, your tmux is doomed. – solotim – 2012-12-25T06:43:58.933

Answers

10

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.

ThomasAdam

Posted 2012-08-02T15:38:14.913

Reputation: 434

This should be the accepted solution, because it works. – polym – 2014-07-25T14:33:17.360

2E.g. setw -g c0-change-trigger 10 setw -g c0-change-interval 250 >> ~/.tmux.conf – DmitrySandalov – 2015-10-01T14:54:34.910

2I tried these on tmux 2.3 and they weren't recognized. It becomes totally unusable when commands spew lots of output. – ijt – 2016-06-29T04:44:45.680

1

Since Tmux 2.1, these options no longer exist according to https://raw.githubusercontent.com/tmux/tmux/2.6/CHANGES

The c0-* options for rate-limiting have been removed.  Instead, a backoff approach is used.
– megar – 2017-12-19T09:49:27.347

7

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.

lukaszkorecki

Posted 2012-08-02T15:38:14.913

Reputation: 171

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.

chepner

Posted 2012-08-02T15:38:14.913

Reputation: 5 645

3

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.

Julien Oster

Posted 2012-08-02T15:38:14.913

Reputation: 151

Strangely enough, this happens when I'm working locally. mosh looks pretty neat, though. – Snowball – 2012-11-13T06:26:46.487

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.

ijt

Posted 2012-08-02T15:38:14.913

Reputation: 131

They appear to be trying to fix this rather than using the workaround, so newer versions should get even better about the output. https://github.com/tmux/tmux/issues/849

– dragon788 – 2017-04-13T18:32:46.077