8

In a (gnome) terminal, if I cat a file which turns out to be much too long, I can always press Ctrl-c to interrupt.

However, in tmux, when the same happens, it takes long for the signal produced by the Ctrl-c keypress to reach the server, and until that happens, the server is busy with this output, and I'm unable to do anything but watching the flood (or using a different terminal).

This is somewhat similar to the problem described here.

I do not wish to restart the terminal, the server, or even the specific tmux window/pane; using less is a smart habit, but I'm asking here about how to solve problems that already occured, not how to be smart and avoiding them by thinking before acting... there will always be surprises!

So, is there a way to let the terminal stop the floods, discard the sent data, etc.? Anything I can do to release myself from these annoying minutes of watching characters on my screen?

Community
  • 1
Bach
  • 827
  • 1
  • 8
  • 11
  • 1
    Give it a look on [SuperUser too](http://superuser.com/questions/456798/tmux-slow-to-interrupt-process-with-ctrl-c/585936#585936) – Hastur Sep 03 '15 at 09:59
  • Not an answer, but you can also use `head` or `tail` to get just enough of output. – MatthewRock Sep 07 '15 at 14:36

2 Answers2

4

Two proposal

  1. Seldom in case like this CTRL+z is more effective than CTRL+c: it answers faster. After that you suspend the command you can kill it with kill %1 or whatever is the job number. In the hope that you are still able to read anything from the screen (a flooding random binary text can easily mess up your characters set).

  2. In another terminal you can ask pgrep cat (if cat was the command invoked) and identify the cat process is using your cpu or by pstree:

    pgrep cat | awk '{print "pstree -sp "$1}' | sh | grep tmux

    answer with an output like
    init(1)---lightdm(1428)---lightdm(2518)---init(2534)---tmux(22425)---bash(22426)---cat(22532)

    In this case, after you have only to kill the cat PID:
    kill 22532

Note:

  • If you press CTRL+C or CTRL+z and after you minimize the window, probably the system will be faster than you to read the interrupt request. So suspend/break, minimize, wait a little, maximize again, can be a solution too.
  • As you said less is safer.
  • Tested again with tmux 1.8 and working
Hastur
  • 2,325
  • 16
  • 32
  • On the contrary @jetole : In IMHO it answers in a general way giving at least two solutions, that you can use even without `tmux`. Of course your proposal can works fine too, or even better, as suggested in a [similar question on Superuser of Apr 22 '13](http://superuser.com/a/585936/257269) – Hastur Sep 03 '15 at 09:57
  • @jetole: Let us avoid any _querelle_: what I posted __I've tried and it works__ as you can guess from the `pstree` output: it was a real one. I think it applies to the situation when op asked _" I'm asking here about how __to solve problems that already occured__, not how to be smart and avoiding them by thinking before acting..."_. Your solution, that I believe it works and solves the problem, it's a solution belonging to the category of _"how to be smart and avoiding them by thinking before..."_ :) – Hastur Sep 05 '15 at 14:14
  • @jetole: I'm sorry to say that you didn't read carefully the answer and the comments. __I have already used this solution under `tmux`__ with a fooding `cat text` command. The `tmux(22425)` in point 2 should tell you. BTW I installed `tmux` on a new machine. It works again as I said before. The example you provide uses an `echo` and over it cycles: you should intercept the `for`, an internal command, to stop the flooding with a `kill PID` command: that means to kill the `tmux` itself as the op do not want. With a single `cat` (as for the op ) there is a process that you can intercept and kill. – Hastur Sep 07 '15 at 15:11
  • When I said _"I'm sorry to say that you didn't read carefully the answer and the comments."_ I meant: __1) in the answer__ there is reported (point 2) the output of `pstree -sp` from which you can see the chain of processes (`-s`) ending with `cat (PID=22532)`.This has for parent a _bash_ that has a for parent the __tmux(22425)__.This means that __I ran that test with tmux__. Check [this link](http://unix.stackexchange.com/posts/138000/revisions) and you to see that it was present since the 1st version of Jun 19th. __2) in the comment__ Sep 5th I explicitely said _"I've tried and works"_. – Hastur Sep 11 '15 at 14:18
  • Now you said many time that it doesn't work. On my tests it works. In which problem did you incur while you tried it with a flooding cat of an huge file (the op case study)? I've done on 2 different machines. The version of _tmux_ is reported in the notes (updated before your last comment). The _distros_ where an Ubuntu 14.04 LTS and a Debian 2.6.32-5, the bash version 4.3.11 and 4.1.2 respectively. – Hastur Sep 11 '15 at 14:35
2

Add the following lines to your tmux.conf (~/.tmux.conf)

set -g c0-change-trigger 150 set -g c0-change-interval 100

More info can be found at http://blog.fraggod.net/2014/09/23/tmux-rate-limiting-magic-against-terminal-spamflood-lock-ups.html

jetole
  • 119
  • 2