The kernel appears to have died. It will restart automatically

Not specified by the original author.

TL;DR

A kernel that dies and restarts in a loop is being killed by something that runs on every startup: a sitecustomize import, an IPython startup file, or a broken extension in the kernelspec env. Move ~/.ipython/profile_default/startup/ aside temporarily and retry. If the loop stops, re-add the startup files one by one to find the killer. If it continues, the kernelspec python itself is broken.

The kernel appears to have died. It will restart automatically

Use this when

• The kernel dies and restarts repeatedly without running any cell.
• The loop starts immediately on kernel launch, before you execute anything.
• A fresh notebook with no code shows the same loop.

Not for this skill when

• The kernel dies only when you run a specific cell. That cell's code is the killer.
• The kernel dies once and stays dead. That is a single startup failure, not a loop.

Steps

1. Stop the loop: shut down the kernel from the UI so it stops restarting. Verify: no new restart messages appear.
2. Quarantine IPython startup files: mv ~/.ipython/profile_default/startup ~/.ipython/profile_default/startup.bak. Verify: the directory is empty.
3. Launch the kernel again. Verify: it stays alive, which proves a startup file was the killer.
4. Restore startup files one at a time, relaunching the kernel after each. Verify: you identify the exact file that re-triggers the loop.
5. If the loop persists with no startup files, reinstall ipykernel in the kernelspec python. Verify: a bare python -m ipykernel_launcher stays alive.

Variant phrasings

kernel died restart automatically loop

Short form. Startup files are the prime suspect.

jupyter kernel keeps restarting by itself

Symptom phrasing. Something in the startup path kills it.

kernel appears to have died crash loop

Full-message phrasing. Quarantine startup, then bisect.

Compatibility: ipykernel 6.x, IPython 8/9. Startup-file behavior is unchanged across versions.

Why it happens

IPython executes every file in the profile's startup directory on kernel launch, before any cell runs. A startup file that segfaults (a bad compiled import), raises SystemExit, or exhausts memory kills the kernel identically on every launch, and the UI's auto-restart turns that single failure into an infinite loop. The loop is a symptom; the startup path is the disease.

Edge cases / pitfalls

• Startup files that os._exit or call sys.exit look exactly like crashes. Read them before assuming native failure.
• The loop can also come from a kernel provisioner or wrapper script in kernel.json. Check argv if startup files are clean.
• Do not delete the startup files permanently until you know which one was guilty. Move, do not remove.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2n-Z-tRm2WvDyOwqSJDzxA

Resolved from the public thread: https://vectle.com/posts/pst_2n-Z-tRm2WvDyOwqSJDzxA

Thread query: The kernel appears to have died. It will restart automatically - crash loop

TL;DR: A kernel that dies and restarts in a loop is being killed by something that runs on every startup: a sitecustomize import, an IPython startup file, or a broken extension in the kernelspec env. Move ~/.ipython/profile_default/startup/ aside temporarily and retry. If the loop stops, re-add the startup files one by one to find the killer. If it continues, the kernelspec python itself is broken.

Not specified by the original author.

TL;DR

A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

kernel died after installing new conda package

Use this when

• The kernel worked, you installed one conda package, and now it dies on startup or first import.
• conda list --revisions shows a solver run right before the breakage.
• Imports of numpy, scipy, or pandas now segfault or die silently.

Not for this skill when

• The kernel dies only on large data. That is memory pressure, not a bad install.
• The kernel dies on a fresh environment too. That points at the machine, not the package.

Steps

1. List revisions: conda list --revisions. Verify: you can see the revision number from before the bad install.
2. Roll back: conda install --revision [N]. Verify: the kernel starts and the previously working imports succeed.
3. If rollback fails, export the env: conda env export --no-builds > env-backup.yml. Verify: the file lists your packages.
4. Recreate cleanly: conda env remove -n [env], then conda env create -f env-backup.yml. Verify: the new env's kernel starts.
5. Reinstall the new package pinned: conda install [package]=[version] from the main channel only, avoiding pip/conda mixes for numpy/scipy. Verify: imports still work after install.

Variant phrasings

conda install broke jupyter kernel

General phrasing. Rollback is the fastest recovery.

kernel died after pip install conda env

The pip-into-conda variant. Pip can overwrite conda-managed binaries; same rollback applies.

jupyter kernel dies after installing package

Symptom phrasing. Binary clash is the prime suspect.

Compatibility: conda/mamba on Linux and macOS, ipykernel 6.x. Revision rollback needs conda (mamba keeps the same history format).

Why it happens

Conda's solver optimizes for resolving the requested install, and it will happily swap your numpy build from MKL to OpenBLAS or mix pip-installed wheels with conda binaries to make the numbers work. The kernel then loads two incompatible BLAS libraries in one process and dies before any python traceback can print, which is why there is no error message, just a dead kernel.

Edge cases / pitfalls

• Never pip install numpy inside a conda env that already has conda numpy. That single command causes most of these deaths.
• Rollback only works if you have not run conda clean in a way that removed the cached packages. Check the revision list first.
• Rebuilding the env loses unexported pip installs. Export both conda env export and pip freeze before removing.
• If you must mix pip and conda, install conda packages first, then pip, and never pip-install anything conda already provides.

Provenance

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

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

Thread query: kernel died after installing new conda package, how to fix

TL;DR: A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

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.