Closing VS Code notebook orphans dotnet processes on MacOS

[kallanreed]

VS Code extension on Mac version v1.0.2462010 #!about Version: 1.0.246201+da749355d416da20e634e5c80073b92356b57e0e

MacOS using VS Code Version: 1.60.2 macOS Big Sur 11.6

Open/create a dib notebook. After running a C# cell, close VS Code with Cmd-Q. There are two dotnet processes each consuming a whole core.

I have to kill these processes manually because they aren't killed when VS Code exits.

[mmabdpr]

This happens also on Linux (Fedora 34, Kernel 5.14.9-200.fc34.x86_64).

VS Code Version: 1.62.0-insider .Net Interactive Extension Version: v1.0.2506041 Dotnet Version: 5.0.206

Running ">.Net Interactive: Stop all notebook kernels" using the command palette does not help.

[joanimato]

I'm also experiencing the same issue on MacOS.

[IanMatthewHuff]

This issue is actually a bit rough as I don't need to open a .NET specific notebook to repro it. If I open vscode-insiders two times and only open up a python jupyter notebook each time after I've closed everything down I have dotnet processes still running and chewing my CPU up. I don't have to open or run a .NET notebook. The processes never go away until I manually kill them.

[jonsequitur]

@IanMatthewHuff I can't reproduce the case where dotnet process are starting when I don't open a notebook. Do you have other extensions installed in VS Code that might be starting them?

[IanMatthewHuff]

@jonsequitur Apologies I was out on Monday / Tuesday. I'll try chopping down the extension list today and check out the repro. Could very well be some type of interaction between Jupyter extension and the .NET interactive extension (I do need to use both of those though).

Just to note I may not have phrased this correctly:

when I don't open a notebook

I do have to open a notebook to repro this. I just don't have to open a notebook with a .NET notebook controller or with a .NET language. So I repro this if I open up a Python language notebook that has already been set with a Python notebook controller (using a kernel provided by the Jupyter extension).

As long as I can swing some time I'd love to help with resolving this. I was enjoying using the .NET interactive notebooks while doing some side learning, but as things currently are I need to enable and then disable the extension every time I use it. Will update today if I get time to investigate.

[IanMatthewHuff]

1. Cleared any dotnet and dotnet-interactive processes running on the system, fully closed down VS Code and VS Code - Insiders instances.
2. Disabled all extensions and reloaded VSCode - Insiders.
3. Enabled .NET interactive (which also auto-enabled the required Jupyter extensions). Version is 1.0.2606011 and looks to be the current version.
4. Opened up a Python .ipynb file.
5. .NET Interactive diagnostic window at this point
6. Activity Monitor at this point
7. Close the .ipynb document (no change to processes)
8. Close down VS Code - Insiders fully. Wait for a few minutes.
9. dotnet processes are still there and one of them goes close to 100% CPU and stays at that %CPU until manually killed.

(.debugEnv) Ians-MacBook-Pro:DebuggingDemo ianhuff$ ps -p 34005
  PID TTY           TIME CMD
34005 ??        10:20.33 /usr/local/share/dotnet/dotnet /Users/ianhuff/.nuget/packages/microsoft.dotnet-interactive/1.0.260601/tools/net6.0/any/Microsoft.DotNet.Interactive.App.dll notebook-parser

Helpful at all? I can collect more if needed.

[jonsequitur]

@IanMatthewHuff Very helpful. Thanks!

[DonJayamanne]

Unfortunately I too have been running into this almost from day 1. Sadly this is why I only enable the extension when I really need this. We had similar issues with the .NET language server for Python in the Python extension.

Its possible that Ian and I run into this often because we're on Mac.

[jakob753951]

Just for completeness sake: When opening a new python notebook without the .NET interactive notebooks extension loaded, there is no dotnet process. When opening a new python notebook with the .NET interactive notebooks extension loaded, the dotnet process is created and lingers after closing VS Code. This seems to happen mostly on MacOS systems regardless of Processor architecture.

[jonsequitur]

This is the same issue as #1005.

[nhirschey]

I am teaching a university class with F# .net interactive notebooks and this bug is really hitting my students on Apple Silicon Macs hard. It's very high impact.

[MatisseHack]

Looks like this has been fixed in VS Code - Insiders. Any word on when the fix will make its way to vanilla VS Code?

[jonsequitur]

The fix should also be in stable VS Code.

If you're still seeing the problem, could you make sure any pending VS Code and extension updates are installed?

[MatisseHack]

I think I'm all up to date.

VS Code info:

Version: 1.67.2
Commit: c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
Date: 2022-05-17T18:20:57.384Z
Electron: 17.4.1
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Darwin x64 21.5.0

Extension info:

Name: .NET Interactive Notebooks
Id: ms-dotnettools.dotnet-interactive-vscode
Description: .NET Interactive Notebooks for VS Code.  Git SHA fb92056d56659000bfa06f89c3878bab466ec05f
Version: 1.0.3256010
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.dotnet-interactive-vscode

Unfortunately I still get a dotnet process pegging one CPU to almost 100% if I quit VS Code after having a notebook open. I don't see the issue when using VS Code - Insiders on the same machine.

[MatisseHack]

And now I'm not experiencing the issue in stable VS Code any more! I received updates to both VS Code and the extension soon after posting that. Thanks for this fix, it's a huge improvement!

[jonsequitur]

I'm seeing this issue again.

Version: 1.0.336204+b3c79a386ecdd5b487649ae0f557851a5da43df9
Library version: 1.0.0-beta.22362.4+b3c79a386ecdd5b487649ae0f557851a5da43df9
Build date: 2022-07-12T22:53:48.0000000Z

[AlexeyRaga]

I see this issue on MacOS, Intel hardware. I can 100% reproduce the issue this way:

• I only have one .dib file in the project and nothing else;
• I open the notebook and 4 (!) dotnet processes appear in the list of running processes;
• I run some cells, then quit VSCode (Cmd+Q)
• 2 of dotnet processes stop, but 2 still remain.

What makes it worse is that one of the "orphan" processes starts eating 99% CPU after I exit VSCode. Which feels like a backstab because it starts draining my battery and wasting CPU only after I abandon it by closing VSCode :)

Needless to say that "Reload window" command in VSCode causes the same behaviour but makes it worse, because when I close VSCode there'll be two dotnet processes eating 99% CPU each, etc.

And reloading is sometimes necessary because the notebook wouldn't refresh data in certain cases (e.g. updated image files in markdown cells), but it is a different story...

[jonsequitur]

I'm not able to repro this on an M1 Macbook Pro.

Version: 1.0.345202+1f7cb23c53cee7fedf47418a0b0321090034af16 Library version: 1.0.0-beta.22452.2+1f7cb23c53cee7fedf47418a0b0321090034af16 Build date: 2022-09-02T23:45:44.0000000Z

[MatisseHack]

It's happening to me again too. If I open a .NET notebook, there will always be a dotnet process using 99% of my CPU once I quit VS Code.

I'm on an Intel MacBook with the following extension information:

Name: .NET Interactive Notebooks
Id: ms-dotnettools.dotnet-interactive-vscode
Description: .NET Interactive Notebooks for VS Code.  Git SHA c74adf6802e8197798c4f22292b61ae72d8b4337
Version: 1.0.3452020
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.dotnet-interactive-vscode

[GeneralMelchett]

Hi, I'm having exactly the same problem on Apple silicon.

Extension details:

Name: .NET Interactive Notebooks
Id: ms-dotnettools.dotnet-interactive-vscode
Description: .NET Interactive Notebooks for VS Code.  Git SHA 49a7ffed69df4a3ac530c94d2d751b050d2de620
Version: 1.0.3504060
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.dotnet-interactive-vscode

VS Code:

Version: 1.72.2
Commit: d045a5eda657f4d7b676dedbfa7aab8207f8a075
Date: 2022-10-12T22:15:55.763Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 21.4.0
Sandboxed: No

I'm using .Net Interactive to teach some PowerShell and C# courses and this bug is causing me quite a headache.

I've tried using my other Mac (Intel i9 MacBook Pro), but I get exactly the same issue there too.

[jonsequitur]

I'm able to repro this again on the M1 Mac as well.

[bayeslearnerold]

Same here. dotnet is going haywirewire on M1 running under dotnet interactive and vscode. Had to manually close them otherwise I have like several 100% CPU dotnet processes running at the same time.

[kotvytskyi]

I'm experiencing the same issue. The bug makes it impossible to use the tool via Azure Data Studio. Had to drop the extension.

[MatisseHack]

The orphaned dotnet processes have gotten slightly worse for me recently. I now have to "force quit" the dotnet processes to get them to stop.

For others still encountering this issue, one solution is to uninstall the "Polyglot Notebooks" extension completely. You can still use the "Jupyter" extension with .NET Interactive kernels by running the following commands:

dotnet tool install --global Microsoft.dotnet-interactive
dotnet interactive jupyter install --path ~/Library/Jupyter/kernels

After restarting VS Code, you can create a new Jupyter notebook and select ".NET (C#)" (or F#/PowerShell) from the kernel picker. The drawback to this workaround is that .dib files and IntelliSense don’t work any more (although I believe version 3.17 of the language server protocol added notebook support so maybe IntelliSense could be supported in the future).

This workaround also doesn’t completely fix the issue! There will still be orphaned dotnet (and now dotnet-interactive) processes. However, at least the orphaned processes are mostly idle (they don’t peg the CPU at 100%). I periodically clear them out with pkill -INT dotnet-interactive. Not a great solution, but it’s what I’m using for now.

By switching to the “Jupyter” extension, I’ve also been able to compare the .NET Interactive kernel directly to kernels from other languages. I’ve found that kernels for Python, TypeScript, and Go all get shut down as soon as the active kernel changes or the notebook closes, whereas the .NET Interactive kernel processes never exit. This behavior indicates to me that the true fix for this issue might be in the .NET Interactive kernel directly rather than the VS Code extension. I’m not familiar with the kernel spec, but perhaps there’s a way for the kernel to shut itself down when it losses connection?

[james-world]

I am running into this as well on an M2 Macbook Air - using Python only notebooks in VS Code. Only option is to manually kill the rogue dotnet process, which was started with:

/usr/local/share/dotnet/dotnet /Users/myuser/.nuget/packages/microsoft.dotnet-interactive/1.0.417201/tools/net7.0/any/Microsoft.DotNet.Interactive.App.dll notebook-parser

Just opening a Python .ipynb file in VS Code and quitting VS Code is enough to repro.

[jonsequitur]

@james-world, what's the CPU usage like on those processes?

[james-world]

@james-world, what's the CPU usage like on those processes?

One process pegged at 99-100% CPU (1 core). This screenshot taken after loading VS Code, opening a simple notebook with one Python cell, running it and quitting VS Code:

Had a look at the process - there are a bunch of threads all spending most of their time here: https://github.com/dotnet/interactive/blob/20680e232e0a13bef0b300003e918948e7ac2c23/src/Microsoft.DotNet.Interactive.Documents/ParserServer/NotebookParserServer.cs#L44

I guess maybe they are spinning round that loop because the NotebookParserServer instances haven't been disposed for some reason.

[jonsequitur]

What version of Polyglot Notebooks are you using? Do you have any updates pending?

[james-world]

v1.0.4172011 and no updates pending.

[1of13]

Do you happen to have any updates on this? I had to uninstall the polyglot notebook to stop the CPU overload--it was a pain in the ass having to force-quit the processes constantly.