agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

Not specified by the original author.

TL;DR

An agent stuck watching a runaway cell with no interrupt capability can only wait, and waiting is not a strategy. Expose the kernel interrupt through the agent's toolset (the client's interrupt_kernel call), add runaway detection (execution time past a budget with no output), and set the policy: interrupt once, inspect, then either retry with a fix or fail with the cell attached. An agent that cannot interrupt cannot operate kernels safely.

agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

Use this when

• An agent watches a cell run past all reasonable time with no way to stop it.
• The agent's toolset lacks a kernel interrupt action.
• Runaway cells block the agent's entire run loop.

Not for this skill when

• A human's runaway cell. Interrupt it from the UI yourself.
• The cell is slow but progressing. That needs patience or optimization.

Steps

1. Expose interrupt: wire the kernel client's interrupt call into the agent's tools. Verify: the agent interrupts a test sleep cell.
2. Define runaway: execution time past N minutes with no new output. Verify: the detector fires on a synthetic hang.
3. Set the policy: interrupt once, capture the cell source and partial output, then decide (fix and retry, or fail). Verify: the policy runs end to end on a test.
4. Log every interrupt with the cell source and the elapsed time. Verify: the log explains why the agent intervened.
5. Fix the underlying runaway (loop guard, timeout, smaller input). Verify: the cell completes without intervention.

Variant phrasings

agent interrupt runaway cell

Short form. Expose interrupt, detect, policy.

agent stuck busy kernel no interrupt

The symptom phrasing. The toolset is missing interrupt.

kernel interrupt capability agent

The capability phrasing. Wire it into the tools.

Compatibility: jupyterclient interruptkernel with ipykernel 6.x. The policy layer is agent-side.

Why it happens

Interrupting a kernel is a distinct operation from waiting or restarting: it asks the running code to stop while preserving the kernel. Agents built only with execute-and-wait have no such operation, so a runaway cell converts the agent into a spectator. The capability is one client call; the value is entirely in the detection and policy around it.

Edge cases / pitfalls

• Interrupt does not reach native code (see the uninterruptible-kernel case). The policy needs a restart fallback.
• Interrupting too eagerly kills slow-but-valid work. Size the runaway budget from measured runtimes.
• After an interrupt, kernel state may be partial. The agent should treat post-interrupt state as suspect.
• An agent that interrupts and silently retries can loop. Interrupt once per cell, then escalate.

Provenance

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

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

Thread query: agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

TL;DR: An agent stuck watching a runaway cell with no interrupt capability can only wait, and waiting is not a strategy. Expose the kernel interrupt through the agent's toolset (the client's interrupt_kernel call), add runaway detection (execution time past a budget with no output), and set the policy: interrupt once, inspect, then either retry with a fix or fail with the cell attached. An agent that cannot interrupt cannot operate kernels safely.

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

An agent that starts a papermill run and waits forever is missing two things: a per-run timeout and the ability to interrupt the kernel. Set papermill's execution timeout so hangs become named failures, and give the agent a kernel-interrupt action it can use when progress stalls. The agent's run loop should watch cell progress (execution counts advancing) and treat a stalled count as a hang, not as patience.

agent's papermill run hung on a cell the agent never interrupted, agent stuck waiting

Use this when

• An agent's papermill invocation hangs and the agent waits indefinitely.
• The agent has no interrupt capability in its toolset.
• Runs hang on cells with loops, sleeps, or blocking I/O.

Not for this skill when

• A human's papermill hangs. Set the timeout and interrupt it yourself.
• The run fails fast. That is a bug, not a hang.

Steps

1. Set an execution timeout on every agent-driven papermill run. Verify: a hung run now fails with the cell named.
2. Give the agent a kernel interrupt tool (interrupt_kernel via the client). Verify: the agent can interrupt a test hang.
3. Add progress watching: the agent checks execution counts or log output periodically. Verify: a stalled count is detected within minutes.
4. Define the hang policy: interrupt once, then fail the run with the cell source attached. Verify: the policy triggers on a synthetic hang.
5. Fix the underlying hanging cell (loop guard, timeout, event wait). Verify: the run completes without needing the policy.

Variant phrasings

agent papermill hang no interrupt

Short form. Timeout plus interrupt tool.

papermill run stuck agent waiting

The symptom phrasing. Watch progress, not just completion.

agent cannot interrupt hung cell

The capability phrasing. Add the interrupt action.

Compatibility: papermill 2.x, jupyter_client kernel management. The pattern fits any agent framework.

Why it happens

Papermill's default is to wait forever, and an agent without an interrupt tool inherits that default with no escape hatch. Humans interrupt hung cells reflexively; agents need the capability explicitly built and the policy for when to use it. Without both, the agent's run loop is a fancy way to wait forever.

Edge cases / pitfalls

• An interrupt that the agent never uses is decoration. The progress watcher is what triggers it.
• Interrupting and retrying the same hanging cell loops forever. Interrupt once, then fail and report.
• The timeout must be generous enough for legitimately slow cells or the agent will interrupt real work.
• Log the cell source on hang. The human fixing it needs to see the code, not just the cell number.

Provenance

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

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

Thread query: agent's papermill run hung on a cell the agent never interrupted, agent stuck waiting

TL;DR: An agent that starts a papermill run and waits forever is missing two things: a per-run timeout and the ability to interrupt the kernel. Set papermill's execution timeout so hangs become named failures, and give the agent a kernel-interrupt action it can use when progress stalls. The agent's run loop should watch cell progress (execution counts advancing) and treat a stalled count as a hang, not as patience.