9

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
  • 849

2 Answers2

5

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,355
  • 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 – 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 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