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

Graceful shutdown does not seems to happen with default profile that launches PowerShell #18017

New Issue
Closed
opened 2026-01-31 06:01:20 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 06:01:20 +00:00
Owner
Copy Link

Originally created by @thadguidry on GitHub (Jul 23, 2022).

Windows Terminal version

1.15.2002.0

Windows build number

10.0.22622.0

Other Software

OpenRefine 3.6

Please work with our developers to help understand this issue more, as we want the best Windows 11 experience for our OpenRefine users.
Our mailing list dev thread for this issue is here: https://groups.google.com/g/openrefine-dev/c/f8krfDFGaQg/m/tj2SX0vRAgAJ

Steps to reproduce

  1. download and double click on the OpenRefine 3.6 executable file openrefine.exe (bottom left screen)
  2. the default profile on Windows 11 launches and runs the application using PowerShell (top left screen)
  3. I press ctrl+c on my keyboard and the process is exited immediately with no graceful shutdown (likely because the signals sent to the application are different now?)
  4. If I open a PowerShell in Terminal tab (top right screenshot) and manually launch OpenRefine with .\openrefine.exe it will run and if I press ctrl-c on my keyboard, then it seems the correct signals are sent and OpenRefine begins it's graceful shutdown as it has done consistently in conhost.exe and cmd.exe since Windows 98.
  5. Modify the default termination behavior with "closeOnExit": "graceful" and save (bottom right screen) and test the default profile again by double-clicking on openrefine.exe
  6. then in the launched new terminal running OpenRefine, press ctrl+c to attempt to gracefully shutdown, but notice that it continues to exhibit an immediate exit and display code (oxc000013a) and seemingly not sending the same signals as it does if the application is launched by running the command line .\openrefine.exe.

Expected Behavior

image

I would expect that since PowerShell is being used in both the default profile in the run app context (double clicking openrefine.exe and the manually launched Terminal in the command line context (.\openrefine.exe), that it would result in the same termination behavior, but it does not.

Actual Behavior

the default profile with PowerShell seems to exhibit slightly different termination signals sent to the application when in the context of a command-line (.\openrefine.exe) or a run behavior (double-clicking on openrefine.exe icon)
We are not confident that the same signals are being sent in both contexts, such as historically $? = 128 + SIGINT = 130

Originally created by @thadguidry on GitHub (Jul 23, 2022). ### Windows Terminal version 1.15.2002.0 ### Windows build number 10.0.22622.0 ### Other Software OpenRefine 3.6 Please work with our developers to help understand this issue more, as we want the best Windows 11 experience for our OpenRefine users. Our mailing list dev thread for this issue is here: https://groups.google.com/g/openrefine-dev/c/f8krfDFGaQg/m/tj2SX0vRAgAJ ### Steps to reproduce 1. download and double click on the OpenRefine 3.6 executable file `openrefine.exe` (bottom left screen) 2. the default profile on Windows 11 launches and runs the application using PowerShell (top left screen) 3. I press `ctrl+c` on my keyboard and the process is exited immediately with no graceful shutdown (likely because the signals sent to the application are different now?) 4. If I open a PowerShell in Terminal tab (top right screenshot) and manually launch OpenRefine with `.\openrefine.exe` it will run and if I press `ctrl-c` on my keyboard, then it seems the correct signals are sent and OpenRefine begins it's graceful shutdown as it has done consistently in conhost.exe and cmd.exe since Windows 98. 5. Modify the default termination behavior with `"closeOnExit": "graceful"` and save (bottom right screen) and test the default profile again by double-clicking on `openrefine.exe` 6. then in the launched new terminal running OpenRefine, press `ctrl+c` to attempt to gracefully shutdown, but notice that it continues to exhibit an immediate exit and display code (oxc000013a) and seemingly not sending the same signals as it does if the application is launched by running the command line `.\openrefine.exe`. ### Expected Behavior ![image](https://user-images.githubusercontent.com/986438/180611155-9d5f453c-9444-4ac8-84f0-652fa3c28cc0.png) I would expect that since PowerShell is being used in both the default profile in the run app context (double clicking `openrefine.exe` and the manually launched Terminal in the command line context (`.\openrefine.exe`), that it would result in the same termination behavior, but it does not. ### Actual Behavior the default profile with PowerShell seems to exhibit slightly different termination signals sent to the application when in the context of a command-line (`.\openrefine.exe`) or a run behavior (double-clicking on `openrefine.exe` icon) We are not confident that the same signals are being sent in both contexts, such as historically $? = 128 + SIGINT = 130
claunia added the Issue-QuestionNeeds-TriageNeeds-Tag-FixNeeds-Attention labels 2026-01-31 06:01:20 +00:00
claunia commented 2026-01-31 06:01:22 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2022):

Interesting! So, there's something strange afoot here.

Look at this:

image

In orange, the PowerShell prompt comes back. In green, however, the application continues producing output.

If I had to guess, it's that OpenRefine spawns a subprocess that is attached to the same console as the original/root OpenRefine process. Further, that root process is terminating with the ^C error code.

Now, Terminal tracks the root process and terminates the connection when that process exits.

When there's a shell, Terminal ends up keeping the connection open until the shell exits. When OpenRefine is running directly inside Terminal, and it gets a ^C, the connection stops since the root process exits.

This is an area in which we're a bit deficient: we don't track an entire process tree the way the console used to, so we are susceptible to a little bit of a behavioral difference in process lifetime and teardown order.

There's a couple ways to fix this. One is going to be to wait for us to fix it -- we have some plans here -- which might take a while. The other is for OpenRefine to effectively join/wait-for its child process to terminate after getting the signal before exiting the parent.

Thoughts?

@DHowett commented on GitHub (Jul 25, 2022): _Interesting!_ So, there's something strange afoot here. Look at this: ![image](https://user-images.githubusercontent.com/189190/180846027-d4d13889-29ce-4139-9a6d-9c2979d2ca14.png) In orange, the PowerShell prompt comes back. In green, however, the application continues producing output. If I had to guess, it's that OpenRefine spawns a subprocess that is attached to the same console as the original/root OpenRefine process. Further, that root process is terminating with the `^C` error code. Now, Terminal tracks the root process and terminates the connection when that process exits. When there's a shell, Terminal ends up keeping the connection open until the _shell_ exits. When OpenRefine is running directly inside Terminal, and it gets a `^C`, the connection stops since the root process exits. This is an area in which we're a bit deficient: we don't track an entire process tree the way the console used to, so we are susceptible to a little bit of a behavioral difference in process lifetime and teardown order. There's a couple ways to fix this. One is going to be to wait for us to fix it -- we have some plans here -- which might take a while. The other is for OpenRefine to effectively join/wait-for its child process to terminate after getting the signal before exiting the parent. Thoughts?
claunia commented 2026-01-31 06:01:22 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 25, 2022):

As an aside - when you run openrefine.exe, the profile that gets used isn't the profile set as the defaultProfile, it instead uses the settings from the profiles.defaults block. So putting closeOnExit: graceful into the powershell.exe profile won't apply to when you run openrefine.exe directly. That's something that changed fairly recently, I wanna say around 1.12.

@zadjii-msft commented on GitHub (Jul 25, 2022): As an aside - when you run openrefine.exe, the profile that gets used isn't the profile set as the `defaultProfile`, it instead uses the settings from the `profiles.defaults` block. So putting `closeOnExit: graceful` into the powershell.exe profile won't apply to when you run openrefine.exe directly. That's something that changed fairly recently, I wanna say around 1.12.
claunia commented 2026-01-31 06:01:22 +00:00
Author
Owner
Copy Link

@thadguidry commented on GitHub (Jul 26, 2022):

So, the suggestion to fix on our end or your end is...? What is the timeline fix on your end...about a year or less? Then that might be fine for us actually.

@thadguidry commented on GitHub (Jul 26, 2022): So, the suggestion to fix on our end or your end is...? What is the timeline fix on your end...about a year or less? Then that might be fine for us actually.
claunia commented 2026-01-31 06:01:22 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 5, 2022):

Sorry, this must've gotten lost in the queue.

There's a couple ways to fix this. One is going to be to wait for us to fix it -- we have some plans here -- which might take a while.

I don't know for sure what Dustin was talking about here - he's being a little too coy for me to decipher this time. He might have meant the closeOnExit: automatic thing(#13560), which I believe shipped in the latest 1.15 release.

Does that work more as expected/?

If not, then I'm not really sure about the other idea he was talking about.

@zadjii-msft commented on GitHub (Dec 5, 2022): Sorry, this must've gotten lost in the queue. > There's a couple ways to fix this. One is going to be to wait for us to fix it -- we have some plans here -- which might take a while. I don't know for sure what Dustin was talking about here - he's being a little too coy for me to decipher this time. He might have meant the `closeOnExit: automatic` thing(#13560), which I believe shipped in the latest 1.15 release. Does that work more as expected/? If not, then I'm not really sure about the other idea he was talking about.
claunia commented 2026-01-31 06:01:23 +00:00
Author
Owner
Copy Link

@thadguidry commented on GitHub (Dec 7, 2022):

Tested closeOnExit: automatic and it did not perform a graceful shutdown. We will look into improving the situation on our end.
Closing for now.

@thadguidry commented on GitHub (Dec 7, 2022): Tested `closeOnExit: automatic` and it did not perform a graceful shutdown. We will look into improving the situation on our end. Closing for now.
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-Question Needs-Attention Needs-Tag-Fix Needs-Triage
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#18017
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?