Closed evfro closed 8 months ago
Thanks to the deep analysis performed by Kevin Bates in https://github.com/jupyter/notebook/issues/5985, it was identified that the problem is likely to stem from the nb_conda_kernel.runner
script, which doesn't ensure process inheritance
leading to both interrupt_events and signals not flowing to the "child" process
I hope, this information will help to make progress on fixing the issue.
Thanks to the deep analysis
Let's call it more of a hunch.
I know it has been three years but I thought I'd try this now, with JupyterLab 4.1.2, and I am able to interrupt a kernel running in another conda environment.
I will close this as stale but if we can get a reproducible test case we can re-open
Description
This is a cross-issue, originally reported at jupyterlab/jupyterlab#8388. The steps to reproduce are also fully described there.
In short, when
nb_conda_kernels
is enabled, it's not possible to interrupt execution of cells from within the JupyterLab's interface if the kernel is not from the same env where JupyterLab is installed.I'm duplicating it here after a short discussion in Anaconda-Platform/nb_conda_kernels#155. In addition to it, below is log from terminal, corresponding to the steps that reproduce the issue.
Logs
Launching external ipython kernel from the dropdown menu activated by
nb_conda_kernels
:Executing a for loop in a cell and trying to interrupt it by hitting stop button 2 times:
It had no effect, the loop continued to run and got fully exhausted with no interruption, no
KeyboardInterrupt
message appeared.Now switching to the original kernel the JupyterLab is from:
Again executing the for loop and hitting the stop button right after it started:
This time cell execution interrupts immediately as expected. I can see the
KeyboardInterrupt
message.Analysis
There seem to be a discrepancy between conda prefix and actually used kernel, which is from a different environment. Not sure if it matters, though.