Stopping output from a program run in SSH session NOW

I usually run the output into less so that I can kill it via less instead using the q key.

$ cmd | less

Example

$ cat /dev/urandom | less

   

After hitting q+Enter it'll quit and return back to your normal terminal, leaving it nice and clean.

Why does that happen?

The problem you're encountering is that there are buffers (for STDOUT) that are being queued up with the output of your display. These buffers get filled so quickly that you're unable to interrupt it fast enough to stop it.

                                    

To disable/limit this effect you can disable the STDOUT buffering which should make things a bit more responsive using stdbuf, but you'll likely have to play with these settings to get things the way you want. To unbuffer STDOUT you can use this command:

$ stdbuf -o0 <cmd>

The man page for stdbuf details the options at your disposal:

    If MODE is 'L' the corresponding stream will be line buffered.  This 
    option is invalid with standard input.

    If MODE is '0' the corresponding stream will be unbuffered.

    Otherwise MODE is a number which may be followed by one of the 
    following: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so
    on for G, T, P, E, Z, Y.  In this case the corresponding stream will be 
    fully buffered with the  buffer  size  set  to  MODE
    bytes.

For a nice background on how buffering works I highly suggest taking a look at this Pixel Beat articled titled: buffering in standard streams. It even includes nice pictures.

References

• Turn off buffering in pipe

Some of that output will be buffered. You send your Ctrl+C to the remote end which interrupts the running program. The program exists and the shell send the characters to show you the prompt again. Before the prompt is shown your screen will first show all the data that was buffered and already on it's way to you.

What you're asking is for the program to stop and the data in transit to somehow disappear. That can't happen as it's already en-route.

The only way you can make sure that you don't see this data is to exit the terminal at your end and then re-connect to your remote - but that's probably far more effort than waiting for the buffered data to display.

There are several levels of buffering. When you press Ctrl+C, this stops the program from emitting data to the terminal. This doesn't affect data that the terminal emulator hasn't displayed yet.

When you're displaying data at very high speed, the terminal can't keep up and will lag. That's what's going on here: displaying text is at lot more expensive than producing these random numbers. Yes, even with a bitmap font — producing cryptographic-quality random numbers is dirt cheap in comparison. (I just tried on my machine and the X process saturated the CPU, with xterm taking a few % and cat (which the random number generation is accounted against) barely reaching 1%. And that's with a bitmap font.)

If you want this to just stop now, kill the terminal emulator. If you don't wish to do that, at least minimize the window; intelligent terminal emulators (such as xterm) will not map the window, which saves the X CPU time, so the garbage will finish displaying quicker. The X server has high priority, so this will make a big difference to your machine's responsiveness while xterm is processing the data in the background.

When all this is going on in a remote shell, the lag is even worse, because the data produced by cat has to first go through the SSH connection. Your press of Ctrl+C also has to go through the SSH connection; it gets somewhat higher priority (it's sent out of band), but that still takes some time during which more output accumulates. There's no way to suppress data in transit short of closing the SSH connection (which you can do by pressing Enter then ~.).