vscode-jupyter: VSCode leaves several running processes after exit

Perhaps if we change the daemon to start as a process group, it should kill the child process automatically.

The root cause of this bug is the daemon’s we spin up to make kernel’s launch faster.

I believe you can workaround the problem by eliminating these files here (copy them elsewhere first in case that breaks something else):

<extension dir>/pythonFiles/lib/python/pyls_jsonrpc

Downside is longer startup times for kernels. But that’s relative. On some windows machines this can cost you 3-5 seconds for startup. On a linux box, it’s a lot less time.

@greazer this was never fixed. I’ve observed it few weeks ago. Please reopen.

I can confirm this behavior of leaving a stale python instance of -m ipykernel_launcher still happens with current versions of vscode on an up to date Ubuntu 20.04 OS:

code --version
1.59.0
379476f0e13988d90fab105c5c19e7abc8b1dea8
x64

And

$ code --list-extensions --show-versions | grep jupyter
ms-toolsai.jupyter@2021.8.1236758218

By the way code -s is useful to see the ipykernel_launcher instances started. Close vscode, and the python ipykernel_launcher PIDs get orphaned and picked up/owned by the systemd user session pid because vscode failed to reap those processes when closing.

To find details of stuff left behind/not cleaned up by vscode:

ps -f -p $(pgrep -f ipykernel_launcher) | more

To see exactly which IPython orphans have ended up owned by the user init instance of systemd:

ps -f -p $(pgrep -P $(pgrep -u $UID systemd) -f ipykernel_launcher) | more

Note pgrep only matches immediate child with -P; no recursion down to deeper child process of running vscode instances.

To kill/cleanup just the orphaned IPython instances (and reclaim your RAM!):

pkill -P $(pgrep -u $UID systemd) -f ipykernel_launcher

Old bug with no new comments for nearly a year. Closing.

Next week sometime it will be in stable. Pre-release is certainly less stable. It ships every night after running our tests.

You need the latest jupyter prerelease extension. As of me writing this comment it would be:

And disabling python daemons definitely fixes the problem.

Oh no wait, I can repro if I close VS code

I am experiencing a similar problem. Here are my specs

Version: 1.61.2
Date: 2021-10-19T14:58:13.605Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.14.14-200.fc34.x86_64

and I am using Fedora 34.

When I run a .ipynb code, I see these instances

and after closing the VSCode

So the VSCode and its related things are being closed in couple of seconds however the python instance still runs.

Details of the python process

Another major problem is that, another ’ python’ process appears after closing the VSCode and when I run another/same .ipynb file. For example, I run a .ipynb code, closed the VSCode, and rerun the same code. After doing this 4 times, I am seeing this.

As you can see, there are 4 .ipykernel_launcer instances, and each of them is taking about 130 MB RAM, which I believe is a lot. I think this is a severe problem.

root cause of this bug is the daemon’s we spin up to make kernel’s launch faster.

Thanks @rchiodo

So far, removing pyls_jsonrpc seems to work:

mkdir /tmp/ipy_buggy_launch
mv ~/.vscode/extensions/ms-toolsai.jupyter-2021.8.1236758218/pythonFiles/lib/python/pyls_jsonrpc /tmp/ipy_buggy_launch

Since doing this, haven’t yet reproduced orphaned IPython instances after vscode closes.

Same issue here, two users SSHing into a GCP ubuntu server. Closing VSCode will leave many suspended processes for python language server and the ipykernel

Both users are running the official version vscode downloaded from code.visualstudio.com

Well, this is pretty rad… So, I’ve tried the official version of vscode and it was correctly cleaning up all the processes as you said.

Next, I went ahead and completely nuked all the directories associated with vscode-oss that I could find. IIRC they were: ~/.vscode-oss ~/.cache/Microsoft and ~/.config/Code - OSS.

Then, launched vscode-oss, reinstalled the Python extension and now it seems to work fine… nothing is left behind… 😕

Now, the interesting part is that the ~/.cache/Microsoft dir is no longer being created. Maybe some bad juju inside it was causing this?..

@rchiodo if you don’t mind, I’d like to keep this issue open for a few more days while I do some more intensive testing. I will come back here and close if all is good.

Thanks. This may be unavoidable depending upon the machine. VS code gives all extensions 5 seconds to finish shutdown. If we don’t get called to close our processes before that 5 seconds is up, they’ll stay running.

We’ll investigate though. We might not be closing the processes in the first place.