Orphaned processes when terminal is force-closed by windows itself #13580

@craigloewen-msft commented on GitHub (Nov 2, 2021):

@zadjii-msft this isn't something I'm aware of from the WSL side

@craigloewen-msft commented on GitHub (Nov 2, 2021): @zadjii-msft this isn't something I'm aware of from the WSL side

claunia commented

@getify commented on GitHub (Nov 3, 2021):

I have an update: I am still seeing orphaned processes... Here's two screenshots, the first one is what my ps ax output showed just a few minutes ago, after I had closed my Terminal app and re-opened it fresh with a single tab.

Now here's what the process list looks like after I did a computer re-start.

As you can see in the previous screenshot compared to this fresh one, before the restart there's a whole bunch of orphaned "init" and "bash" processes there, all of which come from previous tab sessions I had open at some point when the Terminal window was closed (in some way or another).

@getify commented on GitHub (Nov 3, 2021): I have an update: I am still seeing orphaned processes... Here's two screenshots, the first one is what my `ps ax` output showed just a few minutes ago, after I had closed my Terminal app and re-opened it fresh with a single tab. <img width="355" alt="before-restart" src="https://user-images.githubusercontent.com/150330/140064728-025cb936-c096-49b9-b49d-a068dadee5fa.png"> Now here's what the process list looks like after I did a computer re-start. <img width="355" alt="after-restart" src="https://user-images.githubusercontent.com/150330/140064793-37d3898b-0a85-4082-8f7b-7e4d46c4619c.png"> As you can see in the previous screenshot compared to this fresh one, before the restart there's a whole bunch of orphaned "init" and "bash" processes there, all of which come from previous tab sessions I had open at some point when the Terminal window was closed (in some way or another).

claunia commented

@chrisan commented on GitHub (Nov 3, 2021):

This sounds like the discussion in #9914 which actually didn't end up getting triaged before (my bad). @chrisan can you follow up in that thread? Specifically, I'm interested if this consistently happens with the children of one particular type of shell? For example, does this always happen with WSL processes, or does it happen with children running in powershell.exe too?

Thanks!

/dup #9914

Just following up from the duplicate issue (sorry!) This does indeed consistently happen with WSL Ubuntu 20.4 and windows store updates.

My normal dev is to have a local dev server via Laravel's php artisan serve and another to check for TypeScript changes and recompile. I leave both of these on pretty much 100% of the time and let my computer sleep each night after work. In the mornings when I notice my terminal has been closed I will try to restart these process and get notified a port is already in use. This is when I open task manager and kill the bash processes then load terminal again to try starting the local dev tools again

I'm sorry I am not a powershell user, but if there is a command you'd like me to have running as a test for the next time windows store does an update I won't mind having that run. Also I will need to know a way that it is already running orphaned like I can tell with WSL and the bash processes, basically what should I look for wrt powershell processes.

@chrisan commented on GitHub (Nov 3, 2021): > This sounds like the discussion in #9914 which actually didn't end up getting triaged before (my bad). @chrisan can you follow up in that thread? Specifically, I'm interested if this consistently happens with the children of one particular type of shell? For example, does this always happen with WSL processes, or does it happen with children running in `powershell.exe` too? > > Thanks! > > /dup #9914 Just following up from the duplicate issue (sorry!) This does indeed consistently happen with WSL Ubuntu 20.4 and windows store updates. My normal dev is to have a local dev server via Laravel's `php artisan serve` and another to check for TypeScript changes and recompile. I leave both of these on pretty much 100% of the time and let my computer sleep each night after work. In the mornings when I notice my terminal has been closed I will try to restart these process and get notified a port is already in use. This is when I open task manager and kill the bash processes then load terminal again to try starting the local dev tools again I'm sorry I am not a powershell user, but if there is a command you'd like me to have running as a test for the next time windows store does an update I won't mind having that run. Also I will need to know a way that it is already running orphaned like I can tell with WSL and the bash processes, basically what should I look for wrt powershell processes.

claunia commented

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

@craigloewen-msft Can you follow up with the rest of the WSL team and see if there's any thoughts they have on the matter? I'm not sure what the Terminal should be doing better here to make sure that the WSL processes are terminated in the same way that other win32 console apps are.

I don't know what the best way to repro this reliably - maybe we could install an older Terminal version manually (from the Releases page), then search for updates in the store. That should cause the store to update the package, orphaning the processes. If we wanted to do it all again, we should be able to just uninstall the Terminal and try again.

@zadjii-msft commented on GitHub (Nov 3, 2021): @craigloewen-msft Can you follow up with the rest of the WSL team and see if there's any thoughts they have on the matter? I'm not sure what the Terminal should be doing better here to make sure that the WSL processes are terminated in the same way that other win32 console apps are. I don't know what the best way to repro this reliably - maybe we could install an older Terminal version manually (from the Releases page), then search for updates in the store. That should cause the store to update the package, orphaning the processes. If we wanted to do it all again, we should be able to just uninstall the Terminal and try again.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2021):

@benhillis to see if you have any ideas how we might debug this (aside from the weird manual install path above), or if you have any other WSL-side input that might be useful for debugging this

@zadjii-msft commented on GitHub (Nov 8, 2021): @benhillis to see if you have any ideas how we might debug this (aside from the weird manual install path above), or if you have any other WSL-side input that might be useful for debugging this

claunia commented

@june07 commented on GitHub (Feb 6, 2022):

Same deal here and this problem has been ongoing since using terminal (over a year now). Can see the terminal process in the task manager and yet the terminal itself is nowhere to be found. Processes that were opened via the terminal are still running fine and visible in the process manager, however there is no way to re-attach to the terminal!

@june07 commented on GitHub (Feb 6, 2022): Same deal here and this problem has been ongoing since using terminal (over a year now). Can see the terminal process in the task manager and yet the terminal itself is nowhere to be found. Processes that were opened via the terminal are still running fine and visible in the process manager, however there is no way to re-attach to the terminal!

claunia commented

@getify commented on GitHub (Apr 12, 2022):

Just reporting this is still happening... Something from earlier today (dunno what) closed my Windows Terminal instance. When I relaunched it just now, I ran ps ax in the first tab I opened, and here's what it says:

That's a lot of bash/terminal sessions orphaned. Frustrating.

@getify commented on GitHub (Apr 12, 2022): Just reporting this is still happening... Something from earlier today (dunno what) closed my Windows Terminal instance. When I relaunched it just now, I ran `ps ax` in the first tab I opened, and here's what it says: <img width="488" alt="Screenshot 2022-04-12 160943" src="https://user-images.githubusercontent.com/150330/163055448-d14ac96c-e322-49ba-8480-25ced837a80d.png"> That's a lot of bash/terminal sessions orphaned. Frustrating.

claunia commented

@june07 commented on GitHub (Apr 13, 2022):

Same deal for me... just happened yesterday.

@june07 commented on GitHub (Apr 13, 2022): Same deal for me... just happened yesterday.

claunia commented

@therealcodeninja commented on GitHub (Apr 22, 2022):

Same here. It doesn't happen often thankfully, but when it does I have to go and kill the processes.

@therealcodeninja commented on GitHub (Apr 22, 2022): Same here. It doesn't happen often thankfully, but when it does I have to go and kill the processes.

claunia commented

@wolfgang-koch commented on GitHub (Apr 23, 2022):

Happened to me on two different machines these past days as well. I'd happily appreciate if we could turn auto-updating off and instead just get a notification within terminal.

@wolfgang-koch commented on GitHub (Apr 23, 2022): Happened to me on two different machines these past days as well. I'd happily appreciate if we could turn auto-updating off and instead just get a notification within terminal.

claunia commented

@zinodaur commented on GitHub (Jul 24, 2022):

+1 still happening. I guess its better that they are orphaned instead of terminated. Will start using WSL2 sessions inside of a tmux so that I can rescue them if this happens

@zinodaur commented on GitHub (Jul 24, 2022): +1 still happening. I guess its better that they are orphaned instead of terminated. Will start using WSL2 sessions inside of a `tmux` so that I can rescue them if this happens

claunia commented

@daviewales commented on GitHub (Jul 27, 2022):

I just got this with PowerShell.
I logged in this morning, and my Windows Terminal is gone, but all my running processes are still there:

I was right in the middle of a debugging session too, so it's going to be a pain to get back to where I was.
Why does Windows think it's OK to forcibly close my terminal while it's running?!!

EDIT: Looks like I got hit by #6726:

@daviewales commented on GitHub (Jul 27, 2022): I just got this with PowerShell. I logged in this morning, and my Windows Terminal is gone, but all my running processes are still there: ![image](https://user-images.githubusercontent.com/2499066/181132447-080d4660-cc6d-4c87-b951-49a56c49cba1.png) ![image](https://user-images.githubusercontent.com/2499066/181132412-1f07207c-fed6-4179-b6a3-8a709da74f03.png) ![image](https://user-images.githubusercontent.com/2499066/181132363-73636eb4-8397-402c-b8bb-67e3a8e90974.png) I was right in the middle of a debugging session too, so it's going to be a pain to get back to where I was. Why does Windows think it's OK to forcibly close my terminal while it's running?!! **EDIT**: Looks like I got hit by #6726: ![image](https://user-images.githubusercontent.com/2499066/181136051-d91917b7-6be5-4ac9-b1a7-778e37100cb1.png)

claunia commented

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

This might have been mitigated by #13614. Once that ships, the subsequent update shouldn't do this anymore. E.g. that PR will land in 1.16.A. When 1.16.A is installed, this will still happen. Whenever 1.16.B arrives, or 1.17, then that update shouldn't cause this again. So it'll probably be a few months before we can confirm, but I think it'll help.

@zadjii-msft commented on GitHub (Jul 29, 2022): This might have been mitigated by #13614. Once that ships, the _subsequent_ update shouldn't do this anymore. E.g. that PR will land in 1.16.A. When 1.16.A is installed, this will still happen. Whenever 1.16.B arrives, or 1.17, then _that_ update shouldn't cause this again. So it'll probably be a few months before we can confirm, but I think it'll help.

claunia commented

@getify commented on GitHub (Jul 29, 2022):

@zadjii-msft That thread isn't clear (to me)... does quitting vs closing actually mean that the terminal will kill all its currently running (incl background) child processes?

@getify commented on GitHub (Jul 29, 2022): @zadjii-msft That thread isn't clear (to me)... does quitting vs closing actually mean that the terminal will kill all its currently running (incl background) child processes?

claunia commented

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

Theoretically, yes. I think I found a mechanism by which the OS will tell us if we are about to be updated. When that happens

currently, we do nothing. Eventually, the store comes at us and force-kills us. My hypothesis is that this causes the processes to get orphaned.
After that PR: we'll gracefully quit. The processes should get exited in the same way as if you "Quit" the terminal via the command palette.

I could be wrong, this is definitely just a hypothesis.

@zadjii-msft commented on GitHub (Jul 29, 2022): Theoretically, yes. I think I found a mechanism by which the OS will tell us if we are about to be updated. When that happens * currently, we do nothing. Eventually, the store comes at us and force-kills us. My hypothesis is that this causes the processes to get orphaned. * After that PR: we'll gracefully quit. The processes should get exited in the same way as if you "Quit" the terminal via the command palette. I could be wrong, this is definitely just a hypothesis.

claunia commented

@getify commented on GitHub (Jul 29, 2022):

I just tried running a background command tail -f network-log.txt & from a bash shell tab, and then issuing exit to close the tab. The tab closed fine, but when I did ps ax from another tab, the background process was still running.

Then I closed the whole terminal instance (all tabs), and re-opened. The background process was still running, as was the /init parent process for it. I then killed the tail -f background process, and both of them went away.

I guess my point is, I don't think assuming that "clean shutdown" means "don't orphan processes" is going to fix the full issue. It may improve it, but... I think the assumption is that any process which was started by a terminal session, goes away if that terminal session goes away. And that doesn't appear to be the case even in a clean shutdown, much less in a non-clean shutdown.

@getify commented on GitHub (Jul 29, 2022): I just tried running a background command `tail -f network-log.txt &` from a bash shell tab, and then issuing `exit` to close the tab. The tab closed fine, but when I did `ps ax` from another tab, the background process was still running. Then I closed the whole terminal instance (all tabs), and re-opened. The background process was still running, as was the `/init` parent process for it. I then killed the `tail -f` background process, and both of them went away. I guess my point is, I don't think assuming that "clean shutdown" means "don't orphan processes" is going to fix the full issue. It may improve it, but... I think the assumption is that any process which was started by a terminal session, goes away if that terminal session goes away. And that doesn't appear to be the case even in a clean shutdown, much less in a non-clean shutdown.

claunia commented

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

I just tried running a background command tail -f network-log.txt & from a bash shell tab, and then issuing exit to close the tab. The tab closed fine, but when I did ps ax from another tab, the background process was still running

I mean, that repros even in a conhost window. That's not really a terminal issue, that's a part of WSL&linux itself. The tail process isn't attached to the console anymore, so closing the console doesn't close it. Heck, that repros even with gnome-terminal running in the same WSL instance. Once the process is detached from the tty, closing the terminal isn't gonna do anything.

The issue I'm more worried about is us unintentionally orphaning processes, during upgrade, when they should be closed during a normal exit.

@zadjii-msft commented on GitHub (Jul 29, 2022): > I just tried running a background command `tail -f network-log.txt &` from a bash shell tab, and then issuing `exit` to close the tab. The tab closed fine, but when I did `ps ax` from another tab, the background process was still running I mean, that repros even in a conhost window. That's not really a _terminal_ issue, that's a part of WSL&linux itself. The `tail` process isn't attached to the console anymore, so closing the console doesn't close it. Heck, that repros even with `gnome-terminal` running in the same WSL instance. Once the process is detached from the tty, closing the terminal isn't gonna do anything. The issue I'm more worried about is us unintentionally orphaning processes, during upgrade, when they _should_ be closed during a normal exit.

claunia commented

@getify commented on GitHub (Jul 29, 2022):

The tail process isn't attached to the console anymore

I'm certainly no linux expert, so I may be missing something critical here. But I believe you can bring a background process back to a console/tty terminal session, so it doesn't seem like it's entirely disconnected/independent.

At least on my linux systems, it's not really possible to "close" the terminal, as it's part of the OS and is always available, so it doesn't seem to translate here, where terminal is an app that can completely close.

I'm just asserting that I think it's not an uncommon assumption that everything that a program spawns can get killed off when you close the main program.

@getify commented on GitHub (Jul 29, 2022): > The tail process isn't attached to the console anymore I'm certainly no linux expert, so I may be missing something critical here. But I believe you can bring a background process back to a console/tty terminal session, so it doesn't seem like it's entirely disconnected/independent. At least on my linux systems, it's not really possible to "close" the terminal, as it's part of the OS and is always available, so it doesn't seem to translate here, where terminal is an app that can completely close. I'm just asserting that I think it's not an uncommon assumption that everything that a program spawns can get killed off when you close the main program.

claunia commented

@g-regor commented on GitHub (Jul 30, 2022):

Killing all the subprocesses might not be the best solution. In this orphaned state they are still running and might actually finish their job.

Could it be possible to remember the subprocesses, before the terminal is closed for update and ask to reattach or close them on the next run?

@g-regor commented on GitHub (Jul 30, 2022): Killing all the subprocesses might not be the best solution. In this orphaned state they are still running and might actually finish their job. Could it be possible to remember the subprocesses, before the terminal is closed for update and ask to reattach or close them on the next run?

claunia commented

@getify commented on GitHub (Jul 30, 2022):

I like @g-regor's suggestion, that seems much better.

@getify commented on GitHub (Jul 30, 2022): I like @g-regor's suggestion, that seems much better.

claunia commented

@zadjii-msft commented on GitHub (Aug 1, 2022):

Okay so I think we're confusing two bits of this thread. If the updating the Terminal is causing foreground processes to get orphaned, then that's a real issue. However, after rereading the thread, it seems like that's not the issue. It seems like what's happening is that there are processes running in the background in WSL, the Terminal is getting updated, but those processes aren't getting killed. And that all seems by design - the processes are no longer connected to any console session, so there's no reason they should recieve any exit signal from the console (attached to the Terminal) closing.

This is pretty standard even in linux OS's - detaching a process from the terminal, and then killing the terminal, doesn't quit out of everything that was once attached to the terminal (but is now in the background). That we're not about to change here either.

I could've swore there was a better way to reattach to bg processes, but after reading a couple S/O posts [one, two], seems like that's not trivial. Maybe I'm just so used to doing everything in tmux that I assumed it was a default feature.

I don't think it would be possible for the Terminal to somehow maintain a live pty for these foreground processes across reboots, and then reattach to that pty. I also don't think it's possible for the Terminal to create a new pty for these background processes and attach to them, certainly not trivially. (happy to be proven wrong)

Now, looking at https://github.com/microsoft/terminal/issues/9914#issuecomment-1097224160, that screenshot shows a whole pile of bash processes that are listed with pts, with Ss+. So WSL thinks they're all attached to some terminal, in interruptible sleep (waiting for an event to complete), they're the session leader, and they're in the foreground process group. That to me suggests that the processes did get orphaned despite being in the foreground. That we should fix, and is what should be fixed by #13614 in a few releases time.

@zadjii-msft commented on GitHub (Aug 1, 2022): Okay so I think we're confusing two bits of this thread. If the updating the Terminal is causing foreground processes to get orphaned, then that's a real issue. However, after rereading the thread, it seems like that's not the issue. It seems like what's happening is that there are processes running in the background in WSL, the Terminal is getting updated, but those processes aren't getting killed. And that all seems by design - the processes are no longer connected to any console session, so there's no reason they should recieve any exit signal from the console (attached to the Terminal) closing. This is pretty standard even in linux OS's - detaching a process from the terminal, and then killing the terminal, doesn't quit out of everything that was once attached to the terminal (but is now in the background). That we're not about to change here either. I could've swore there was a better way to reattach to bg processes, but after reading a couple S/O posts [[one](https://unix.stackexchange.com/questions/4034/how-can-i-disown-a-running-process-and-associate-it-to-a-new-screen-shell), [two](https://unix.stackexchange.com/questions/31824/how-do-i-attach-a-terminal-to-a-detached-process)], seems like that's not trivial. Maybe I'm just so used to doing everything in `tmux` that I assumed it was a default feature. I don't think it would be possible for the Terminal to somehow maintain a live pty for these foreground processes across reboots, and then reattach to that pty. I also don't think it's possible for the Terminal to create a new pty for these background processes and attach to them, certainly not trivially. (happy to be proven wrong) Now, looking at https://github.com/microsoft/terminal/issues/9914#issuecomment-1097224160, that screenshot shows a whole pile of `bash` processes that are listed with `pts`, with `Ss+`. So WSL thinks they're all attached to some terminal, in interruptible sleep (waiting for an event to complete), they're the session leader, and they're in the foreground process group. That to me suggests that the processes _did_ get orphaned despite being in the foreground. That we should fix, and is what should be fixed by #13614 in a few releases time.

claunia commented

@getify commented on GitHub (Aug 2, 2022):

Okay so I think we're confusing two bits of this thread.

I don't think things are particularly confused. I think there's two kinds of processes that are getting abandoned when a terminal session shuts down (or restarts itself). Some of those are, indeed, bash sessions (active foreground processes) and some of those might be background processes spun off from those.

What I'm asserting is, if windows can force-close a terminal window, it shouldn't completely abandon either kind of process.

Either killing them all off, or (as @g-regor suggested), resume them all after the next start.

I admit I don't know how difficult it would be, but it seems like Terminal could/should remember each time one of its tab processes creates a new process, and if (right when it's shutting down) it sees that process is still running, it should either kill it (regardless of if it's a foreground or background process), OR it could just save that list of process-IDs, and on next restart, it checks to see if those are still there.

If it's not possible to resume, it could prompt the user with those processes and ask what they want to do for each, like "Kill this one? vs Leave it alone."

@getify commented on GitHub (Aug 2, 2022): > Okay so I think we're confusing two bits of this thread. I don't think things are particularly confused. I think there's two kinds of processes that are getting abandoned when a terminal session shuts down (or restarts itself). Some of those are, indeed, bash sessions (active foreground processes) and some of those *might* be background processes spun off from those. What I'm asserting is, if windows can force-close a terminal window, it shouldn't completely abandon either kind of process. Either killing them all off, or (as @g-regor suggested), resume them all after the next start. I admit I don't know how difficult it would be, but it seems like Terminal could/should *remember* each time one of its tab processes creates a new process, and if (right when it's shutting down) it sees that process is still running, it should either kill it (regardless of if it's a foreground or background process), OR it could just save that list of process-IDs, and on next restart, it checks to see if those are still there. If it's not possible to resume, it could prompt the user with those processes and ask what they want to do for each, like "Kill this one? vs Leave it alone."

claunia commented

2026-01-31 03:46:33 +00:00

@getify commented on GitHub (Aug 2, 2022):

For reference on foreground vs background, it's fairly common for me to start up node web-server instances in my bash sessions. Sometimes I leave those as foreground (thereby tying up the bash session in that tab), and sometimes I suspend them to a background process.

If my Terminal app dies, I don't want any of those foreground Node server instances still running, attached to orphaned bash sessions, because they're still tying up a localhost network port. But I also don't want any background Node server instances still running as zombies, for the same reason.

@getify commented on GitHub (Aug 2, 2022): For reference on foreground vs background, it's fairly common for me to start up node web-server instances in my bash sessions. Sometimes I leave those as foreground (thereby tying up the bash session in that tab), and sometimes I suspend them to a background process. If my Terminal app dies, I don't want any of those foreground Node server instances still running, attached to orphaned bash sessions, because they're still tying up a localhost network port. But I also don't want any background Node server instances still running as zombies, for the same reason.

claunia commented

@daviewales commented on GitHub (Aug 2, 2022):

If the updating the Terminal is causing foreground processes to get orphaned, then that's a real issue.

This is exactly what happened to my foreground PowerShell processes when the friendly Windows Store forcibly closed my terminal while I was asleep...

@daviewales commented on GitHub (Aug 2, 2022): > If the updating the Terminal is causing foreground processes to get orphaned, then that's a real issue. This is exactly what happened to my foreground PowerShell processes when the friendly Windows Store forcibly closed my terminal while I was asleep...

claunia commented

2026-01-31 03:46:33 +00:00

@getify commented on GitHub (Aug 2, 2022):

Here's another idea: how about just not closing Terminal when it's being updated. It's a more important kind of program than your typical app, and it often is used in very-long-running scenarios. Instead of force updating and restarting, the update feature should tell the user that the update will be applied on the next restart of the app, and let the user choose (and handle all the processes).

@getify commented on GitHub (Aug 2, 2022): Here's another idea: how about just not closing Terminal when it's being updated. It's a more important kind of program than your typical app, and it often is used in very-long-running scenarios. Instead of force updating and restarting, the update feature should tell the user that the update will be applied on the next restart of the app, and let the user choose (and handle all the processes).

claunia commented

2026-01-31 03:46:34 +00:00

@j4james commented on GitHub (Aug 2, 2022):

Here's another idea: how about just not closing Terminal when it's being updated.

There's an upcoming Store change which I think will give you that option. See https://github.com/microsoft/terminal/issues/6726#issuecomment-1147358557

@j4james commented on GitHub (Aug 2, 2022): > Here's another idea: how about just not closing Terminal when it's being updated. There's an upcoming Store change which I think will give you that option. See https://github.com/microsoft/terminal/issues/6726#issuecomment-1147358557

claunia commented

2026-01-31 03:46:34 +00:00

@zadjii-msft commented on GitHub (Aug 2, 2022):

Here's another idea: how about just not closing Terminal when it's being updated

There are plenty of other threads on that specific topic - I'm gonna pretty explicitly keep this thread on-topic to the orphaning processes issue. See See https://github.com/microsoft/terminal/issues/6726#issuecomment-1147358557 for more. (thanks for the link @j4james)

@zadjii-msft commented on GitHub (Aug 2, 2022): > Here's another idea: how about just not closing Terminal when it's being updated There are plenty of other threads on that specific topic - I'm gonna pretty explicitly keep this thread on-topic to the orphaning processes issue. See See https://github.com/microsoft/terminal/issues/6726#issuecomment-1147358557 for more. (thanks for the link @j4james)

claunia commented

2026-01-31 03:46:34 +00:00

@ukdocCT commented on GitHub (Aug 18, 2022):

Following on from this: https://github.com/microsoft/terminal/issues/9914#issuecomment-1199499522

After that PR: we'll gracefully quit. The processes should get exited in the same way as if you "Quit" the terminal via the command palette.

If it gracefully closes (after the initial notification), and then (if) closes all the sessions, or gets forced closed (after the 30s) then that is only slightly better than the current situation. Yes we don't have any orphaned consoles, but it still closes out all our consoles meaning we loose work.

As someone that regularly has a lot of different consoles open doing different things this is just a nightmare. Regularly i will leave something running in a powershell or WSL session to come in the following morning and have no idea where my scripts got to as i have no way of reattaching to the consoles.

As others have said even uninstalling from the store and installing the msixbundle directly still gets picked up by the store and auto updated.

On my home machine i only ever installed via the appxbundle and that never auto-updates and allows me to perform a controlled updated when i have time, but that may be because i dont auto-update my store apps.

Hopefully there will be a way of convincing the store to give up its claim to the manually install msixbundle.

@ukdocCT commented on GitHub (Aug 18, 2022): Following on from this: https://github.com/microsoft/terminal/issues/9914#issuecomment-1199499522 > * After that PR: we'll gracefully quit. The processes should get exited in the same way as if you "Quit" the terminal via the command palette. If it gracefully closes (after the initial notification), and then (if) closes all the sessions, or gets forced closed (after the 30s) then that is only slightly better than the current situation. Yes we don't have any orphaned consoles, but it still closes out all our consoles meaning we loose work. As someone that regularly has a lot of different consoles open doing different things this is just a nightmare. Regularly i will leave something running in a powershell or WSL session to come in the following morning and have no idea where my scripts got to as i have no way of reattaching to the consoles. As others have said even uninstalling from the store and installing the msixbundle directly still gets picked up by the store and auto updated. On my home machine i only ever installed via the appxbundle and that never auto-updates and allows me to perform a controlled updated when i have time, but that may be because i dont auto-update my store apps. Hopefully there will be a way of convincing the store to give up its claim to the manually install msixbundle.

claunia commented

@ricklove commented on GitHub (Oct 6, 2022):

This happens to me about once a month. I wake up in the morning and windows terminal is closed. This is usually about 5 windows with 2-5 tabs each so it's not a great experience.

I actually like the fact that it doesn't kill the process (well if I had a long running process doing some work anyway), but it would be great if it could reconnect each window and tab. (vscode does this well)

Since windows has been begging for an update, I guess it's time to restart now.

@ricklove commented on GitHub (Oct 6, 2022): This happens to me about once a month. I wake up in the morning and windows terminal is closed. This is usually about 5 windows with 2-5 tabs each so it's not a great experience. I actually like the fact that it doesn't kill the process (well if I had a long running process doing some work anyway), but it would be great if it could reconnect each window and tab. (vscode does this well) Since windows has been begging for an update, I guess it's time to restart now.

claunia commented

@getify commented on GitHub (Oct 6, 2022):

FYI:

I recently found this tool reptyr, which re-parents a process to a current tty. YMMV, but it may be helpful as a temporary work-around if you have shell orphaned processes that you'd like to reclaim, and perhaps either shutdown cleanly or just continue to monitor until it completes.

I've tested it on current tty sessions and processes, but I plan to test it on orphaned processes the next time my shell dies thanks to windows (store).

@getify commented on GitHub (Oct 6, 2022): FYI: I recently found this tool [reptyr](https://github.com/nelhage/reptyr), which re-parents a process to a current tty. YMMV, but it may be helpful as a temporary work-around if you have shell orphaned processes that you'd like to reclaim, and perhaps either shutdown cleanly or just continue to monitor until it completes. I've tested it on current tty sessions and processes, but I plan to test it on orphaned processes the next time my shell dies thanks to windows (store).

claunia commented

@ukdocCT commented on GitHub (Oct 7, 2022):

unfortunately, i think that will only reattach linux sessions once inside the linux session - similar to tmux etc, i dont think that will work in Windows with reattaching WSL, batch or similar.

@ukdocCT commented on GitHub (Oct 7, 2022): unfortunately, i think that will only reattach linux sessions once inside the linux session - similar to tmux etc, i dont think that will work in Windows with reattaching WSL, batch or similar.

claunia commented

@zadjii-msft commented on GitHub (May 3, 2023):

Hey so loop back on the original root issue tracked in this thread: "CLI processes are orphaned when the Terminal is updated by the store" - has anyone seen that in the 1.15->1.16+ updates?

In 1.15, we merged #13614, which should have fixed this for the subsequent updates to 1.16 / 1.17. I believe there might have also been some changes to the conpty handling in 1.17 that should have made this more robust.

If it's still happening, then we'll have to go back to the drawing board on finding a setup to repro that consistently.

@zadjii-msft commented on GitHub (May 3, 2023): Hey so loop back on the original root issue tracked in this thread: "CLI processes are orphaned when the Terminal is updated by the store" - has anyone seen that in the 1.15->1.16+ updates? In 1.15, we merged #13614, which should have fixed this for the subsequent updates to 1.16 / 1.17. I believe there might have also been some changes to the conpty handling in 1.17 that should have made this more robust. If it's still happening, then we'll have to go back to the drawing board on finding a setup to repro that consistently.

claunia commented

@getify commented on GitHub (May 3, 2023):

Here's what I'm still seeing regularly:

an update closes the whole app, losing all my tabs -- this super sucks, and I still cannot understand how anyone believes this is the right thing for a long-lived app to be able to forcibly close on update with no restoration. almost no other app (browser, editor, etc) could get away with that.
on occasion (maybe once per month), it seems like an update fails to close my full terminal session, but what it does instead is MUCH worse... it basically crashes the WSL process... I see the CPU on my system start spiking to 60%+ usage, fans spin, and the main process is like "virtual mem" or something. The WSL is then completely unusable, and I cannot even restart the terminal to connect to a new WSL session. I also can't close the process since it's some protected system process. the only fix is to restart the computer.

Also, I know you've triaged this thread as if "forced closed" is somehow a separate issue from my original OP of orphaned processes. I am persisting in linking the two, because they are two sides of the same problem.

I think it's mishandling of my report to say "great, we no longer have orphaned processes" because that was just one smaller aspect of the larger problem. What I meant when I filed this was not ONLY the orphaning, but the fact that force closes ARE THE PROBLEM.

In other words, the bug of orphaned processes is a symptom, not a root cause.

It's not very much comfort that one symptom might have been fixed but the deeper problem is just ignored as off-topic.

@getify commented on GitHub (May 3, 2023): Here's what I'm still seeing regularly: * an update closes the whole app, losing all my tabs -- this super sucks, and I still cannot understand how anyone believes this is the right thing for a long-lived app to be able to forcibly close on update with no restoration. almost no other app (browser, editor, etc) could get away with that. * on occasion (maybe once per month), it seems like an update fails to close my full terminal session, but what it does instead is MUCH worse... it basically crashes the WSL process... I see the CPU on my system start spiking to 60%+ usage, fans spin, and the main process is like "virtual mem" or something. The WSL is then completely unusable, and I cannot even restart the terminal to connect to a new WSL session. I also can't close the process since it's some protected system process. the only fix is to restart the computer. ---- Also, I know you've triaged this thread as if "forced closed" is somehow a separate issue from my original OP of orphaned processes. I am persisting in linking the two, because they are two sides of the same problem. I think it's mishandling of my report to say "great, we no longer have orphaned processes" because that was just one smaller aspect of the larger problem. What I meant when I filed this was not ONLY the orphaning, but the fact that force closes ARE THE PROBLEM. In other words, the bug of orphaned processes is a symptom, not a root cause. It's not very much comfort that one symptom might have been fixed but the deeper problem is just ignored as off-topic.

claunia commented

@ukdocCT commented on GitHub (May 3, 2023):

I believe this is a consequence of it being a UWP app which for the most part i believe are designed to be suspended and restarted without loosing context and data.

I have tried to untangle my install from the store - totally unsuccessfully, so have now turned off auto-updates in the store so that i can control when the updates occur and not loose the dozen or so consoles i have open on my daily machine.

@ukdocCT commented on GitHub (May 3, 2023): I believe this is a consequence of it being a UWP app which for the most part i believe are designed to be suspended and restarted without loosing context and data. I have tried to untangle my install from the store - totally unsuccessfully, so have now turned off auto-updates in the store so that i can control when the updates occur and not loose the dozen or so consoles i have open on my daily machine.

claunia commented

@zadjii-msft commented on GitHub (May 3, 2023):

I like to triage issues as separate root causes. In this case, this report covered two problems:

The store force kills the Terminal to install updates
During an update / force kill, CLI apps get orphaned.

Now, we already have another thread with a very long discussion on the first topic, over in #6726. If that was the only point being made in this thread, I would have long ago closed this as a duplicate.

The orphaning of processes described in this thread is a wholly unique issue, so I choose instead to focus this thread on that particular effect. We can try to remedy that issue independently of the (much harder to resolve) first issue.

I believe this is a consequence of it being a UWP

The Terminal is not a UWP app. That's kind of an outdated notion in 2023. The Terminal is a packaged, full-trust, win32 application that uses UWP XAML, via XAML Islands is the most correct way to describe ~ w h a t ~ the terminal is. In this case, the "packaged" element is the most relevant, because it's the way that the Store interacts with packaged applications that results in what you're describing.

I suspect (using only psychic debugging) that the "an update crashes WSL and spins a CPU" issue is also a side effect of #6726 / "the store kills apps for updates". I'm not a WSL engineer, so I have no idea how to investigate that further. I'd recommend filing this on https://github.com/microsoft/WSL. My psychic debugging theory is that this is also due to the Store killing the WSL package, to update WSL, and they'll need a similar fix as to #6726. (this is something we've discussed offline with them)

@zadjii-msft commented on GitHub (May 3, 2023): I like to triage issues as separate root causes. In this case, this report covered two problems: * The store force kills the Terminal to install updates * During an update / force kill, CLI apps get orphaned. Now, we already have another thread with a very long discussion on the first topic, over in #6726. If that was the only point being made in this thread, I would have _long ago_ closed this as a duplicate. The orphaning of processes described in this thread is a wholly unique issue, so I choose instead to focus this thread on that _particular effect_. We can try to remedy that issue independently of the (much harder to resolve) first issue. <hr> > I believe this is a consequence of it being a UWP The Terminal is not a UWP app. That's kind of an outdated notion in 2023. The Terminal is a _packaged, full-trust, win32 application that uses UWP XAML, via XAML Islands_ is the most correct way to describe ~ w h a t ~ the terminal is. In this case, the "packaged" element is the most relevant, because it's the way that the Store interacts with packaged applications that results in what you're describing. <hr> I suspect (using only psychic debugging) that the "an update crashes WSL and spins a CPU" issue is also a side effect of #6726 / "the store kills apps for updates". I'm not a WSL engineer, so I have no idea how to investigate that further. I'd recommend filing this on https://github.com/microsoft/WSL. My psychic debugging theory is that this is also due to the Store killing the WSL package, to update WSL, and they'll need a similar fix as to #6726. (this is something we've discussed offline with them)

claunia commented