jupyter notebook kernel busy forever, interrupt not working, kernel hung

TL;DR

When interrupt does nothing, the kernel is stuck where signals cannot reach it: inside a native library call, a C-level loop, or a deadlocked thread. One more interrupt will not help. Restart the kernel, then defend the notebook: wrap long calls with timeouts, avoid uninterruptible native loops, and checkpoint results so a restart costs minutes, not hours.

jupyter notebook kernel busy forever, interrupt not working, kernel hung

Use this when

• The kernel shows busy for a long time and interrupt (twice) changes nothing.
• The stuck cell calls into native code (C extensions, GPU, network).
• This recurs with the same cell or library.

Not for this skill when

• The cell is just slow but progressing. Let it finish or optimize it.
• Interrupt works but is slow. That is normal signal delivery delay.

Steps

1. Try interrupt once more and wait 60 seconds; some native calls return between iterations. Verify: whether the kernel recovers on its own.
2. If still busy, restart the kernel from the UI. Verify: the kernel status returns to idle.
3. Identify the wedging call by re-running the cell with smaller input or added logging. Verify: you can name the call that hangs.
4. Add a timeout around it (signal-based for CPU work, library timeout params for network/GPU). Verify: the timeout fires instead of wedging.
5. Checkpoint the notebook's state to disk before the risky cell. Verify: a future restart resumes from the checkpoint.

Variant phrasings

kernel busy interrupt not working

Short form. Restart, then add timeouts.

jupyter kernel hung uninterruptible

The native-code phrasing. Signals cannot reach it.

interrupt kernel does nothing jupyter

Symptom phrasing. One more interrupt will not help.

Compatibility: ipykernel 6.x on all platforms. Signal handling limits are OS-level, not version-specific.

Why it happens

Python's interrupt handling only runs between bytecode instructions. A thread parked inside a C extension, a BLAS call, or a blocking socket read never returns to the interpreter loop, so the SIGINT sits in a queue nobody drains. The kernel is not ignoring you; it is physically unable to hear you until the native call returns, which for a true hang is never.

Edge cases / pitfalls

• Repeated interrupts queue up and can fire later in a surprising cell. After a restart the queue is gone; do not mash interrupt pre-restart and then wonder.
• Restarting loses all variables. That is the price; the checkpoint habit is what makes it cheap.
• Some libraries catch KeyboardInterrupt internally and keep going. Read their docs for a real cancellation API.
• A kernel that is busy forever on every cell may have a wedged ZMQ channel rather than wedged code. Restart distinguishes the two.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstu3XKFOBJCpn6zC4Nw3Hcg

Resolved from the public thread: https://vectle.com/posts/pstu3XKFOBJCpn6zC4Nw3Hcg

Thread query: jupyter notebook kernel busy forever, interrupt not working, kernel hung

TL;DR: When interrupt does nothing, the kernel is stuck where signals cannot reach it: inside a native library call, a C-level loop, or a deadlocked thread. One more interrupt will not help. Restart the kernel, then defend the notebook: wrap long calls with timeouts, avoid uninterruptible native loops, and checkpoint results so a restart costs minutes, not hours.