Javascriptservices: Node process doesn't seem to be released after stopping asp.net core

[asadsahi]

I have observed both on windows 7 and windows 10 that if I run asp.net core spa generator multiple times, e.g start debug, stop, start debug, stop every time I run application it starts node instance and doesn't clean itself, which lead to unexpected behavior such as files are locked after asp.net process is stopped and caching old client files by node/webpack. I am not using any other node application and here is what process explorer looks like:

[SteveSandersonMS]

Could you provide some more info about your setup? As in:

• Are you launching the application in IIS Express, or IIS, or via the dotnet CLI?
• If you're launching from VS, what version of VS?
• What's the version of Node?
• Have you edited your project in any way (and if so, what have you added that might cause the Node process to fail to exit), or does this repro even with a clean new project generated by "yo aspnetcore-spa"?

I ask because I've tried to repro this (launching from dotnet CLI on both Windows and OSX, plus launching into IIS Express from Visual Studio 2015 Update 2 on Windows 10), and was not able repro the issue at all unfortunately - in my trials, the node.exe processes always exited cleanly as soon as the .NET process was ended (as per design).

[asadsahi]

@SteveSandersonMS

I am using VS Code Editor (not VS IDE) all the way and lauching from there which means its dotnet CLI. launching the server.

Node version: 6.3.0

Here is my public repo which I am using and having this issue. Not sure if that can help in running in your environment to eliminate anything wrong with the project or environment.

[MarkPieszak]

You're launching it via F5 and the launch.json for VSCode? Maybe it's VSCode keeping it in memory (unintentionally) and not aborting it properly. Haven't had this happen when I run through normal command-line, can you try a dotnet run in command line and see if it still occurs? @asadsahi

[asadsahi]

@MarkPieszak you are right, with environment set to "Development" and running dotnet run using command line trashes node process as expected. With "Production" environment it isn't even starts a node process, that is expected behaviour as well I believe.

However launching the process using F5 is causing this error to happen. Doesn't dotnet cli remember the node process it is firing to kill after dotnet is stopped irrespective of how it is launched?

[MarkPieszak]

Yeah, it's very interesting... I'm guessing maybe the .dll file for the project itself maybe isn't being created or accessed correctly by VSCode, or maybe more likely, they aren't disposing of the process correctly?

[asadsahi]

@MarkPieszak dll is created, otherwise project will not even run and dll remains in the bin/debug folder until next build of the project with any code change or user manually deletes the dll.

However the question still remains, how vs code cannot kill node process when it has stopped dotnet process. If dotnet process isn't stopped then we should be able to access site in browser even dotnet process is stopped. But after we have stopped the process from vscode, website isn't accessible in browser anymore.

@SteveSandersonMS any ideas?

[SteveSandersonMS]

This was more difficult to fix than I expected. I was able to repro this on both Windows and OS X - as far as I can tell, VS Code terminates the debugged process harshly (similarly to kill -9) so it doesn't have any opportunity to clean up (run .NET finalizers, etc.). Therefore the launched child processes just keep running.

The only reliable cross-platform way I've found for the child process to detect that it's been orphaned is to have it poll to see if the parent process (by PID) is still there. That's what's now implemented here - the child processes should now exit within 1 second of the parent process exiting, no matter how suddenly the parent was shut down or crashed.

[SteveSandersonMS]

@asadsahi When the updated packages are released, can you check whether this does indeed resolve it in your specific setup? It's possible that you have VS Code's launcher configured differently, so I'd like to be sure it really does cover your scenario too!

[MarkPieszak]

Nice one! Reminds of good old setTimeout for a second, to fix weird issues in IE 😶 haha

[asadsahi]

@SteveSandersonMS Thanks for the fix. Sounds complicated than I thought as well :) Sure, will give it a try as soon as got ping for the closure of this issue.

[seriouz]

Thanks! I had this issue, too.

[chesteryang]

@SteveSandersonMS This issue can be reproduced with dotnet core 2.1, angular or react new project template and VS code 1.24.1. But in Visual Studio 2017, no pending nodejs processes after stopping debug.

[optical]

I'm seeing the the same issue as @chesteryang, using core 2.1, react, webpack, combined with UseReactDevelopmentServer and VS Code. When stopping the debugger in VS Code I see orphaned node processes lingering. I haven't dug much further into this

[CodySchrank]

Same as @chesteryang, I'm still seeing this with a new react-redux spa and vscode. I have to start cleaning them out when my fans start spinning (each node process takes a couple cpu percent)!

[tylerbarnett]

Same Issue here, OSX Mojave 10.14, ReactJS Front end and .netcore 2.1. Issue persists on vscode & vscode insiders when running debug F5 command. I have became accustom to using terminal "killall node", however when using node for something else at the same time I am unable to use that command.

[ruimaciel]

I can reproduce this issue with vs code 1.28.2 running .net core 2.2-preview3 on Ubuntu 16.04 by running a fresh react project created with dotnet new react.