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

[feature request] Terminal to show an indicator that underlying WSL does not respond / hung #11865

New Issue
Closed
opened 2026-01-31 02:59:36 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 02:59:36 +00:00
Owner
Copy Link

Originally created by @vadimkantorov on GitHub (Dec 23, 2020).

It stopped responding, and I only can type Ctrl+C. Even the Ctrl+Z sign won't display. When the WSL is unhung (can take many seconds sometimes), all characters are enacted. It would be good for Terminal to display some indicator of this happening, that would be much less confusing.

image

Originally created by @vadimkantorov on GitHub (Dec 23, 2020). It stopped responding, and I only can type Ctrl+C. Even the Ctrl+Z sign won't display. When the WSL is unhung (can take many seconds sometimes), all characters are enacted. It would be good for Terminal to display some indicator of this happening, that would be much less confusing. ![image](https://user-images.githubusercontent.com/1041752/103040600-32754080-4574-11eb-9998-cf52cf453d28.png)
claunia commented 2026-01-31 02:59:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 23, 2020):

Terminal cannot generally know when a process attached to it is not responding because it’s hung versus not responding because it isn’t doing local echo or it’s printing a progress bar or something else.

What leading indicators are unique to a hang that won’t cause false positives? Unless we can pin down a couple, this is more likely to cause users ire than delight.

@DHowett commented on GitHub (Dec 23, 2020): Terminal cannot generally know when a process attached to it is not responding because it’s hung versus not responding because it isn’t doing local echo or it’s printing a progress bar or something else. What leading indicators are unique to a hang that won’t cause false positives? Unless we can pin down a couple, this is more likely to cause users ire than delight.
claunia commented 2026-01-31 02:59:38 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Dec 24, 2020):

In principle, I agree that it's difficult to detect. Also Windows does it somehow for regular apps (when they don't respond to mouse / redraw for a long time).

It's just a situation that almost never happens on regular Linux when ssh is not used (maybe because of general higher perf of Terminal apps / less footprint of underlying bash). Maybe some heartbeat/observability functionality could be (or is already?) implemented in WSL driver. A colored indicator on the tab head that a long-running process is happening may be useful even out of context 100% reliable hang detection.

In my case, it just stops responding on keys typed when - probably again some major page faults for loading from hard drive. There was no active process running.

Not responding to Ctrl+C / Ctrl+Z / Ctrl+\ (when typed) for 10 seconds may be such a hang indicator as well. If the user hit these buttons, a confirmation for them that it's not their fault or the WT fault would be useful ("the app doesn't respond to input for a long time. either kill the tab or wait" like windows shows it for apps), even if it's not 100% accuracte.

@vadimkantorov commented on GitHub (Dec 24, 2020): In principle, I agree that it's difficult to detect. Also Windows does it somehow for regular apps (when they don't respond to mouse / redraw for a long time). It's just a situation that almost never happens on regular Linux when ssh is not used (maybe because of general higher perf of Terminal apps / less footprint of underlying bash). Maybe some heartbeat/observability functionality could be (or is already?) implemented in WSL driver. A colored indicator on the tab head that a long-running process is happening may be useful even out of context 100% reliable hang detection. In my case, it just stops responding on keys typed when - probably again some major page faults for loading from hard drive. There was no active process running. Not responding to Ctrl+C / Ctrl+Z / Ctrl+\ (when typed) for 10 seconds may be such a hang indicator as well. If the user hit these buttons, a confirmation for them that it's not their fault or the WT fault would be useful ("the app doesn't respond to input for a long time. either kill the tab or wait" like windows shows it for apps), even if it's not 100% accuracte.
claunia commented 2026-01-31 02:59:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 3, 2021):

Yea, I don't think there's anyway for us to do this reliably. Even if it's just detecting if the app doesn't emit anything quickly in response to pressing Ctrl+C / Ctrl+Z. Maybe the app is sitting there counting how many times the user presses them. Maybe the terminal is connected to a ssh session with a 12s ping (shudder).

The Terminal certainly isn't the place to be implementing any sort of heartbeat. I'd doubt that WSL would be either, but that's probably a better place to ask than here. I'd really doubt that WSL is going to be able to implement some sort of heartbeat on top of linux though, something about extending existing API surfaces being bad... Win32 can have a heartbeat because it's already expected that each window process has a thread that should always be service messages from the window queue. I'm pretty sure there's nothing like that for commandline applications on either windows or linux.

@zadjii-msft commented on GitHub (Jan 3, 2021): Yea, I don't think there's anyway for us to do this reliably. Even if it's just detecting if the app doesn't emit anything quickly in response to pressing <kbd>Ctrl+C</kbd> / <kbd>Ctrl+Z</kbd>. Maybe the app is sitting there counting how many times the user presses them. Maybe the terminal is connected to a ssh session with a 12s ping (_shudder_). The Terminal certainly isn't the place to be implementing any sort of heartbeat. I'd doubt that WSL would be either, but that's probably a better place to ask than here. I'd really doubt that WSL is going to be able to implement some sort of heartbeat on top of linux though, something about extending existing API surfaces being bad... Win32 can have a heartbeat because it's already expected that each window process has a thread that should always be service messages from the window queue. I'm pretty sure there's nothing like that for commandline applications on either windows or linux.
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 Issue-Feature Needs-Attention Needs-Tag-Fix Needs-Triage Resolution-Won't-Fix
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#11865
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?