-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Node.js processes don't quit after stopping debugging #5204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Until then I guess you can always kill the processes manually |
@bharney Thanks, I am using windows so I can use task manager to kill a process. Another workaround is to launch app in external command line window and after stopping debug, as this window is still on, I can use ctrl+c to terminate it. |
Thanks for contacting us. |
I agree it would be good if we could find a way to do this automatically. I don't know the correct way to launch child process such that they (and all transitive descendant processes) will die automatically if the root process dies, but if there is a way to do that, I expect we'd accept a PR to use that technique. |
You can use job objects. We do this for IIS Express tests (https://github.com/aspnet/AspNetCore/blob/3477daf3c4f530dff80f197e0642cb39a26fb07b/src/Servers/IIS/IntegrationTesting.IIS/src/ProcessTracker.cs) |
This happens for me in VS 2017 Pro 15.9.9 and VS 2019 Preview 4.2. When I start an ASP.NET Core 2.1 or 2.2 React app from VS (with debugging) and stop debugging the node.exe processes remain. If I run outside of VS using |
This also occurs when running in IIS Express without debugging and changing C# code so the process restarts automatically. I find myself going into task manager multiple times per day and cleaning up 10s of orphaned processes. Is there no way this can be patched in 3.1? It is quite annoying to deal with all day, every day. Thanks! |
It seems like Microsoft.AspNetCore.SpaServices.Extensions doesn't specify parent process id: |
Can confirm, having this issue with:
|
I ran across this bug recently after looking at the below announcement Testingafter a bit of testing it looks like this cropped up sometime between version 2.2 and 3.0
Something about the way it's opening the process is leaving the process open after the debug session closes / visual studio quits. For testing I found a repo online that was already setup to use UseReactDevelopmentServer
webpack / vue equivilentI've been looking at creating a webpack equivalent since that's what I'm interested in but it looks like the webpack dev server has the same issue if I copy / paste the code from There's also been one or two Vue dev server implementations floating around on the web that have run into the same problem. CauseI'm not sure of the cause but there's some suggestion that running stuff via "npm start" might not be such as good idea if it's not passing on SIGKILL, SIGTERM and SIGINT
another approach might be to use npx instead to launch the dev server which might be more direct / better so I'll be trying that next in my own implementation for webpack. These are some other links I came across the top one lists a possible better way which involves proxying via the dev server first then the asp .net host second, although I haven't looked into that yet. |
hmm so I just ruled out npm as the issue
leaves nothing open after quitting as that's not a loop / terminates by iteself
keeps the cmd open after stopping debugging / quitting studio so same issue / never terminates
but that didn't do anything / stop it so it must be further up |
Related #11597 |
Annoying...... I created a bat file kill-node.bat and added a postbuild event
set to run post build event "Always" Ill be left with a lingering node between builds, but a pretty good middle ground. |
This was resolved with #11597. |
I'm not sure if this has fixed it, I tried copying the contents of
into my own class library to see if the applicationStoppingToken stuff which had been added in was working Edit
Hopefully this has been fixed somewhere down the line in the latest master |
Update it looks like this does work as long as you don't use IISExpress while debugging Avoiding IISExpress shouldn't be an issue so cool beans |
@ryanbrandenburg any chance this makes it into a 3.x release? |
@drdamour we won't be patching 3.x for this. |
Please refer to dotnet/vscode-csharp#2387 for details.
If there has been a fix, let me know how.
The text was updated successfully, but these errors were encountered: