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/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
  • 533

6 Answers6

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.

poolie
  • 193
ThomasAdam
  • 452
  • 4
  • 3
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.

lukaszkorecki
  • 191
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
  • 7,041
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.

Julien Oster
  • 213
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
  • 131
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.

Jim McGlashan
  • 11