0

On a local terminal, the stty -noflsh option allows to discard buffered output on Ctrl-C and thus prevents from long scrolling delays if one did accidentally output large amounts of text to the terminal.

How to achieve that on a ssh session where the local terminal is in raw mode and thus does not interpret Ctrl-C as interrupt, while the remote pty has already forwarded large quantities of text through the ssh network connection before the interrupt occurs ?

This problem (long scrolling delays even after pressing Ctrl-C) occurs if the network speed is way higher than the scrolling speed of the terminal, which seems to be true anytime as of today, and the buffers in the network connection are large compared to that scrolling speed, which also seems to be true anytime as of today.

Juergen
  • 666

1 Answers1

0

I confirmed the problem in a virtual terminal in my Kubuntu 24.04 LTS. The basic test command was:

ssh -t user@server '</dev/urandom tr -dc "[:alnum:]"'

I tested various terminal settings (by running stty -F … from another console) and I suspect it's not that ssh pushes a lot of data to the terminal and noflsh could discard it. I suspect that the slow terminal makes data accumulate at and/or before ssh.

This means it's not about the terminal, unless you can make it accept data faster (possibly without printing) or you switch to a faster one. To discard incoming data you need help from ssh.

Unfortunately there is not much help you can get from ssh. You can make it disconnect: press Enter~.. Note that Enter will get to the remote side.

Then you will probably want to reconnect; but this will put you in a new remote shell. Consider using tmux on the server side, so in few seconds you can reattach to the session, where the tmux server hopefully has already digested whatever large amounts of text it got.

Still, if ssh to be disconnected is responsible for some tunnels (-L, -R, -D) then the tunnels will break upon disconnection. Consider using separate sshs for tunnels and for interactive use, so one does not affect the other when terminated. If using ControlMaster, keep in mind that terminating the master ssh will terminate each multiplexed session, but terminating ssh that "piggybacks" on the master one won't affect neither the master nor any other ssh. Set up your connections wisely.

You can test the solution even in a fast terminal by using ssh where reading data from the network connection is artificially throttled:

ssh -o ProxyCommand='nc %h %p | pv -qL 100k' -t user@server '</dev/urandom tr -dc "[:alnum:]"'

This won't really give you any clue on how much data gets buffered in the network (because this ProxyCommand adds pipe buffers and the buffer of pv to the stack). The point is not in measuring this; the point is in showing the solution works. I my tests I experience delay of about 8 seconds between Ctrl+c (that causes SIGINT being sent to the remote tr) and the end of output. Ctrl+cEnter~. works immediately.

Kamil Maciorowski
  • 81,893