Fix zombie processes not closing in development

[tjcouch-sil]

It seems sometimes some node processes don't get closed in development. I theorize it may be one of the processes created in this area as it seems the process itself isn't being listened to to close the other processes, and the spawned npm process at this line doesn't get saved off to get closed either. This is an issue with ERB itself, I believe, so it may be worth adding an issue or PR to them as well.

Sometimes esbuild processes don't get closed either, but I don't know if we are going to figure that out... Seems like a Vite issue.

Fixing this may help with #186

[irahopkinson]

The most common issue I see is it just stops after vite2 (probably due to the EPERM error). I'm running in a seperate terminal Windows Terminal) and my console looks typically like this:

And my task manager looks like this:

I've only recently been monitoring the task manager and in this state I just kill both esbuild.exe and all the Node.js JavaScript Runtime tasks and I can try again.

[tjcouch-sil]

The most common issue I see is it just stops after vite2 (probably due to the EPERM error). I'm running in a seperate terminal Windows Terminal) and my console looks typically like this: And my task manager looks like this: I've only recently been monitoring the task manager and in this state I just kill both esbuild.exe and all the Node.js JavaScript Runtime tasks and I can try again.

@irahopkinson any news on trying again after closing those rogue processes that may have been there since before the changes? I haven't seemed to get the esbuild or node processes to zombie yet since my last changes, but I haven't tried extensively by any means.

[tjcouch-sil]

Ooooh it seems Task Manager doesn't update to show the new zombie processes. You have to close and open it. Bummer. After editing things in bundled extensions and the extension template back to back many times, I finally got an EPERM. Here are the command line args for all the rogue node processes. There were also two rogue esbuild processes.

I wonder if I need to investigate the source code of concurrently and/or cross-env...

[tjcouch-sil]

Looks like concurrently has a command-line argument --kill-others-on-fail that may do exactly what we want!

[tjcouch-sil]

Looks like --kill-others-on-fail doesn't solve all our problems unfortunately. Some other ideas:

• Try/catch closing processes in webpack renderer dev? Might have to do with stuff not closing
  • Tried this, and it doesn't work. But I added some debug logs. Looks like maybe not all the processes get closed here - I wonder if they are already gone or are not being closed in the right place or something. Getting ENOSYS on trying to kill the processes, and different processes throw the error when reproducing different times:

Main is closing!
webpack.config.renderer.dev.ts:239
Preload Builder threw an error during closing of Main! Error: kill ENOSYS
webpack.config.renderer.dev.ts:228
Extension Builder threw an error during closing of Main! Error: kill ENOSYS

• Are we killing extension host and dotnet provider (launched from main) on crash? extension-host.service.ts and dotnet-data-provider.service.ts launch them from main.ts
• Does killing extension host kill all its processes? extension-host.service.ts
• At some point in the past, Tim and I worked on similar problems in Changed shutdown to properly wait for sub-processes to shutdown #155, and we discovered that running npm run ... to launch the extension host watcher nodemon was failing to close everything properly. We changed to executing the script we were trying to run manually with node ... instead. Though this may have had at least something to do with the fact that it was running a watcher script, but I'm really not sure. Needs more investigation. Anyway, that could be a culprit in webpack.config.renderer.dev.ts where it's launching many processes and then trying to close them later.
• Maybe it's worth running concurrently on the many processes launched in webpack.config.renderer.dev.ts instead of launching them inside the webpack config?

Notes:

• If you see esbuild running in Task Manager, that means Vite didn't stop properly in some way