starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Open
opened 2026-01-31 01:35:09 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 01:35:09 +00:00
Owner
Copy Link

Originally created by @agostini01 on GitHub (May 29, 2020).

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.

Originally created by @agostini01 on GitHub (May 29, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # 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.
claunia added the Issue-BugProduct-TerminalArea-PerformancePriority-2 labels 2026-01-31 01:35:09 +00:00
claunia commented 2026-01-31 01:35:10 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (May 30, 2020):

i have same problem...

@vadimkantorov commented on GitHub (May 30, 2020): i have same problem...
claunia commented 2026-01-31 01:35:10 +00:00
Author
Owner
Copy Link

@zb140 commented on GitHub (Jun 7, 2020):

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.

@zb140 commented on GitHub (Jun 7, 2020): 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.
claunia commented 2026-01-31 01:35:10 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Jun 8, 2020):

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.

@vadimkantorov commented on GitHub (Jun 8, 2020): 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.
claunia commented 2026-01-31 01:35:10 +00:00
Author
Owner
Copy Link

@agostini01 commented on GitHub (Jun 17, 2020):

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.

@agostini01 commented on GitHub (Jun 17, 2020): Although the issue #1064 is closed, this problem is not fixed. As mentioned in this [comment](https://github.com/microsoft/terminal/issues/1064#issuecomment-637014476), 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.
claunia commented 2026-01-31 01:35:11 +00:00
Author
Owner
Copy Link

@mateuszdrab commented on GitHub (Jun 22, 2020):

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.

@mateuszdrab commented on GitHub (Jun 22, 2020): 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.
claunia commented 2026-01-31 01:35:11 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Jun 22, 2020):

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

@vadimkantorov commented on GitHub (Jun 22, 2020): Canonical example is running dmesg over ssh, impossible to stop it with Ctrl+C or Ctrl+Z
claunia commented 2026-01-31 01:35:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 25, 2020):

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
@DHowett commented on GitHub (Jun 25, 2020): 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 <kbd>^C</kbd> 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 <kbd>C</kbd> key while holding down <kbd>Ctrl</kbd> * 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
claunia commented 2026-01-31 01:35:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 9, 2021):

The root cause here might be #2141

@zadjii-msft commented on GitHub (Aug 9, 2021): The root cause here might be #2141
claunia commented 2026-01-31 01:35:12 +00:00
Author
Owner
Copy Link

@OmarOmeiri commented on GitHub (Nov 12, 2021):

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

@OmarOmeiri commented on GitHub (Nov 12, 2021): To me it was just disbling `Ctrl+C` key binding for copy text.
claunia commented 2026-01-31 01:35:12 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Jul 5, 2022):

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

@vadimkantorov commented on GitHub (Jul 5, 2022): > 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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Performance Issue-Bug Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8669
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?