When a subprocess is run from the notebook, if it gets stuck the kernel will get locked waiting for it. Selecting Kernel/Interrupt from the menu does not terminate the subprocess, but rather leaves the kernel in an unstable, 'partially locked' state, where other cells do not execute. The only resolution is to restart the kernel.

This occurred for me on Windows - I do not know if it also happens on Unix.

To demonstrate, start a notebook and enter !python in a cell. The process will lock as it is waiting for interactive input. As there is no way to provide that input, the kernel must be restarted to continue.

duplicate of #514

Thanks, I hadn't spotted the duplicate. Having said that, t#514 is discussing a much more complex scenario, involving actually interacting with subprocesses (and it seems to be Unix based, as it's about pty-style interaction). For my requirements, a simple means of killing a rogue subprocess would do. Consider something as simple as !sleep 50000, where just being able to kill the sleep is all you want. (Maybe Ctrl-C works for this on Unix, but it doesn't on Windows).

Sorry, I see what you mean now. Reopening as a separate issue - interrupt not interrupting subprocesses on Windows.

I'm not sure this is limited to subprocesses. Try executing input() or raw_input() and then clicking the interrupt button--the kernel hangs and has to be restarted.

@arijun on What OS? interrupting input and raw_input raise KeyboardInterrupt here (OS X).

Sorry, windows. That's why I thought it was likely the same issue @pfmoore had, since that also happened on windows.

Ah, crap. I know what that bug is. I think it's a libzmq (or pyzmq) bug that prevents it from handling interrupts properly while polling on zmq sockets. It's nothing in IPython. sigh

I think I just got bitten by this and I'll need to restart the kernel, meaning I've just lost a lot of data…

I was using pdb to debug a function. I re-ran the cell without first quitting pdb, and now I can't interrupt anything.

Here's a minimal example that reproduces this:

Run this cell twice in a row.

This same issue happens for me in Unix as well word for word.

'When a subprocess is run from the notebook, if it gets stuck the kernel will get locked waiting for it. Selecting Kernel/Interrupt from the menu does not terminate the subprocess, but rather leaves the kernel in an unstable, 'partially locked' state, where other cells do not execute. The only resolution is to restart the kernel.'

Thanks for the nice example of a pdb hang, wmayner. But sInce pdb doesn't run in a subprocess, I opened a separate issue for pdb: #10516

Printing too much data, let's say accidentally printing a gigantic numpy array, can make the kernel completely unresponsive and impossible to to terminate

Has a solution been found for this issue yet? i just ran a machine learning model that took 14hr to complete and now my kernel is stuck and doesnt execute cells. if i restart, i have to run the model again for 14hrs. So is there any solution?

haven't tried it, but this seems like it could help: http://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/limit_output/readme.html

If a specific subprocess has got stuck, you can probably find it in the task manager and forcibly kill it that way. Hopefully that lets the kernel continue.

no, the issue is that the kernel spams the webserver to death or something. killing the webserver kills the kernel afaik

I'm dealing with a stuck notebook too: interrupt, restart, reconnect - none of them do anything. The [*] indicators remain next to cells as if they are queued to run but no cells get executed.

The behavior began after running a cell containing:

Which is strange because I have analogous cells elsewhere that run successfully. I'm not sure how/if ls could get stuck but otherwise my situation seems to match this issue.

Is there any solution to this . Kernal cannot be interrupted .
For me it's happening with GridSearchCV in sklearn .

There was a process named conda.exe in Task manager. I killed that process and I was successfully able to interrupt the kernel

Interrupt is still broken. I have to restart and reload my imports every time.

same problem in jupyter lab on python 3.7 kernel

same problem in Jupyter Notebook and I can't find the process named conda.exe in Task manager. Any updates on the solution yet?

Not a solution
Sometimes trying to reconnect to the kernel helps in this case

Observing the same, in Windows 10

Did anyone succeed on that? I am getting crazy

There was a process named conda.exe in Task manager. I killed that process and I was successfully able to interrupt the kernel

@ahmedrao How????

This problem has existed for six years and still no solution.

This problem has existed for six years and still no solution.

six years without any solution, just restart the kernel

Having the same problem increasingly frequently, almost to the point where the notebooks are becoming unusable which is a real shame. On Anaconda 3.7 and the cells just hang with the asterisk, and I am unable to interrupt the kernel.