Kernel/Interrupt Kernel does not terminate stuck subprocesses in the notebook

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

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

@pfmoore

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:

def test():
    import pdb; pdb.set_trace()  # XXX BREAKPOINT
    return 0

test()

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

I run into this sometimes too... Here is a reproduceable example from jupyer lab:

LOAD DATA

import requests
import pandas as pd

url='https://raw.githubusercontent.com/numenta/NAB/master/data/realKnownCause/nyc_taxi.csv'
r = requests.get(url, allow_redirects=True)
        with open('data/nyc_taxi.csv', 'wb') as f:
            f.write(r.content)
df_taxi = (
        pd.read_csv('data/nyc_taxi.csv')
        .assign(timestamp=lambda x: pd.to_datetime(x.timestamp))
)

df_train = df_taxi.iloc[:5000]
temp_train = df_train.set_index('timestamp')

Run Grid Search: THIS CANNOT BE INTERRUPTED

import itertools
#set parameter range
p = range(0,3)
q = range(1,3)
d = range(1,2)
s = [24,48]

# list of all parameter combos
pdq = list(itertools.product(p, d, q))
seasonal_pdq = list(itertools.product(p, d, q, s))
# SARIMA model pipeline
for param in pdq:
    for param_seasonal in seasonal_pdq:
        try:
            mod = sm.tsa.statespace.SARIMAX(temp_train[:240],
                                            order=param,
                                            seasonal_order=param_seasonal)
            
            results = mod.fit(max_iter = 50, method = 'powell')
            
            print('SARIMA{},{} - AIC:{}'.format(param, param_seasonal, results.aic))
        except as e:
            print(e)
            continue

Is there any advice?

run into this problem three times this afternoon, reminds me of the good old days when i was still using urllib.
thought its on urllib, cause there is no response to my request.
I was working but coding, I have to find a solution but a answer. So I store every variable to local file.
really don't want to see that happen again and again.

I am facing the same issue when using tensorflow and gpu for training deep learning model.

Run into this with time.sleep and requests

Also having this issue with time.sleep requests on Windows, but runs fine on Mac OS X

Having this issue with ThreadPoolExecutor... Something like this:

numberOfImageGatherers = 2

with concurrent.futures.ThreadPoolExecutor(max_workers=numberOfImageGatherers + 1) as executor:
        futures = []

        for imageGatherer in range(numberOfImageGatherers):
            imageDataGatherer = ImageDataGatherer(batch_size)
            futures.append(executor.submit(imageDataGatherer.gatherImageData, pipeline))

        modelTrainingConsumer = ModelTrainingConsumer(vae, plot_losses)    

        futures.append(executor.submit(modelTrainingConsumer.trainModel, pipeline))

        concurrent.futures.wait(futures)

Only way to interrupt is to restart kernel... very frustrating

This is still happening. I would suggest re-opening this issue. Seeing it in a NumPy-heavy tight neural network training loop on Windows 10.

jupyter core     : 4.7.1
jupyter-notebook : 6.2.0
qtconsole        : 4.7.7
ipython          : 7.20.0
ipykernel        : 5.3.4
jupyter client   : 6.1.7
jupyter lab      : 2.2.6
nbconvert        : 6.0.7
ipywidgets       : 7.6.3
nbformat         : 5.1.2
traitlets        : 5.0.5

Is there anything I need to upgrade?

Возникает такая же проблема, и самое интересное в случайных участках кода при использование B0 remote api для coppelia sim. При это если я использую Publisher и Subscriber

I found this solution to stop cell when I work with time sleep or requests:

for i in range(20):
    try:
        print(i)
        time.sleep(1)
    except KeyboardInterrupt:
        print("Stopping...")
        break

Are there any news on this issue? I am working remotely in a Kubernetes pod and, when this occurs, I am completely locked out of the machine. I cannot even open a shell.

@thistlillo

@thistlillo your issue is most likely unrelated to this one. In any case, we would need more information than what you've provided, like: version of IPython and Python you're using, whether you are using Jupyter Notebook or Jupyter Lab, versions of those, etc. And, most importantly, a minimalized set of steps required to reproduce the issue.

If you can provide this info, please create a new issue and include it.

I ran into this issue today on my linux laptop. Although I have not found a way to interrupt the kernel, I was able to save my variables by injecting a pickle.dumps using pyrasite. Thanks to https://stackoverflow.com/a/59124617/18638036

Hey guys! I also had the same issue, but it was a silly mistake on my end.

Avoid using try without adding specific exceptions in your except block you are expecting your code to throw. A generic try looks like this -

try:
    #code here
except:
    #exception handling

It seems like this code would also catches your keyboard Interrupts/ kernel interrupts which registers as KeyboardInterrupt exception (only if execution is inside this try block) .

I thought it might help some unfortunate souls if I share it here.

Just tossing my 🎩 into the ring that I too am experiencing this issue

Its 2025... getting same error, endless cycle of Interrupts kernel dialog while on the children Jupyter notebook to teach adult "programmers" how to program.

Edit:

So need to update VS code and then restart... Jupyter (stuff used to teach kids how to program for "software engineers" 🤣) then doesn't throw the endless "Interrupts kernel dialog". Programmers will get dumb when things are taught via Jupyter, it's so unfortunate.

Navigation Menu

Repository navigation

Kernel/Interrupt Kernel does not terminate stuck subprocesses in the notebook #3400

29 remaining items

LOAD DATA

Run Grid Search: THIS CANNOT BE INTERRUPTED

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Kernel/Interrupt Kernel does not terminate stuck subprocesses in the notebook #3400

Description

Activity

minrk commented on Jun 4, 2013

pfmoore commented on Jun 4, 2013

minrk commented on Jun 13, 2013

arijun commented on Sep 17, 2014

minrk commented on Sep 17, 2014

arijun commented on Sep 18, 2014

minrk commented on Sep 18, 2014

wmayner commented on Mar 31, 2016

lancekrogers commented on Oct 27, 2016

nealmcb commented on May 8, 2017

JulesGM commented on Mar 14, 2018

rajulah commented on May 29, 2018

JulesGM commented on May 29, 2018

29 remaining items

jvschoen commented on Aug 31, 2020

LOAD DATA

Run Grid Search: THIS CANNOT BE INTERRUPTED

dawnset commented on Oct 13, 2020

Crispy13 commented on Oct 20, 2020

matija2209 commented on Nov 17, 2020

mbrad092 commented on Dec 5, 2020

not-Ian commented on Dec 22, 2020

TV4Fun commented on Feb 2, 2021

Esesna commented on Jun 6, 2021

hamitaksln commented on Nov 19, 2021

thistlillo commented on Mar 21, 2022

MrMino commented on Mar 21, 2022

UmarZein commented on Jun 7, 2023

Shubhang9 commented on Jul 6, 2023

ericdrosas87 commented on Apr 4, 2025

rajhlinux commented on Nov 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions