Cannot send CTRL+C signal to remote machine while terminal is rendering text

[agostini01]

Environment

Windows build number:
Microsoft Windows [Version 10.0.18363.836]

Windows Terminal version (if applicable):
Version: 1.0.1401.0

Any other software?

- wsl-ubuntu-18.04
- ssh using wsl to remote computer
- tmux inside the remote computer

Steps to reproduce

Connected to a remote machine with ssh from wsl, running tmux on this remote.

Issue happens when application print lots of contents to the terminal, which prevents the user to send signals (CTRL-C to stop the application from printing to the terminal). You only regain control after the terminal renders EVERYTHING that is being printed.

Other signals such as CTRL+Z or tmux bindings to change the pane scope (to work on other pane or kill the running window also does not get accepted while the printing is happening.

Expected behavior

I expected the CTRL+C to stop the application running the printing. And regain control of the terminal.

Actual behavior

Long running applications that print lots of contents to the terminal prevent the user to send signals (CTRL-C to stop the application from printing to the terminal). You only regain control after the terminal renders everything that is being printed.

[vadimkantorov]

i have same problem...

[zb140]

I have the same issue as well, but without WSL, just using the Windows built-in OpenSSH. Once it's in this state, if I press CTRL-C a whole bunch of times and then wait a few minutes, it will eventually "catch up" and kill the running process. But at first it doesn't appear anything has happened.

[vadimkantorov]

In other terminals (e.g. WSLTTY) I had more success with Ctrl+Z (SIGSTOP) still being processed, even if Ctrl+C (SIGTERM) was not being sent to the process.

Another issue: when pasting by Ctrl+Shift+V some giant text it takes (understandably) an immense amount of time, but it's impossible to cancel the paste. But not sure if anything can be done about this.

[agostini01]

Although the issue #1064 is closed, this problem is not fixed. As mentioned in this comment, it would be expected that priority would be given to user signals instead of finishing the printing to the screen.

Although, while it's writing STDOUT really fast, there is a long delay to interrupt the foreground process, almost as if the terminal is not able to output the text rapidly and send the interruption sequence to the underlying shell. I would imagine that it makes more sense to prioritize the user's input if there's a bottleneck somewhere.

[mateuszdrab]

Similar issue here, Powershell tab running docker.exe attached to a container, after some time I suddenly can't CTRL-C to kill the session. I have to kill the tab instead and start again, quite annoying.

[vadimkantorov]

Canonical example is running dmesg over ssh, impossible to stop it with Ctrl+C or Ctrl+Z

[DHowett]

So, the UI queue unblocking work we did in #3622 #4608 #6492 helped this only a tiny bit. We also still have a long way to go. A really long way.

I just ran yes (which notoriously prints out trillions of lines and causes a bunch of buffer rollover and scrolling) via WSL locally and over an SSH connection. Here's what I got for how long it took ^C to return me to a prompt.

Methodology

I'm using an application on my phone called "Is it Snappy?", which takes high-speed video and lets you scrub frame by frame to mark "input" and "output" frames. It then tells you the time delta between them.

Parameters:

• Command: timeout 10 yes
• Input mark: When I bottom out the C key while holding down Ctrl
• Output mark: First frame where ^C appears in my buffer.

Terminal v1 local (baseline)	local	wsl ssh	win32-openssh
1065.0ms	982ms	10517.1ms (timeout reached)	9701ms (timeout reached)
1231ms	998ms	10101.2ms (timeout reached)	9618ms (timeout reached)

for comparison, here's gnome-terminal in the same WSL instance. The Windows Console subsystem is out of the way. I only did one trial for these. I didn't run win32-openssh because it would use the console subsystem.

It's eating our lunch.

local	wsl ssh
116.7ms	116.7ms

I'm going to dig around for a duplicate of this, as I know we probably have one. It's remarkable how much worse SSH is -- I can't explain that difference very well.

For fun, I measured win32-openssh and wsl ssh in conhost, without Terminal.

wsl ssh	win32-openssh
4043ms	3178.3ms

[zadjii-msft]

The root cause here might be #2141

[OmarOmeiri]

To me it was just disbling Ctrl+C key binding for copy text.

[vadimkantorov]

The root cause here might be #2141

Doing a giant text paste locally (without ssh even) could also be a simple test bed. Ideally there would be a way to "cancel" the paste/endless redraw somehow (although it may be not a true Ctrl+C signal stuff, since it's the terminal itself pasting that should be canceled). But it also blocks the Terminal