debug py3 kernel: kernel error on startup, no traceback in logs

Not specified by the original author.

TL;DR

An empty kernel error means the kernel process died before it could log anything, so the first job is making it talk. Start the server with --debug, find the kernelspec with jupyter kernelspec list, read its kernel.json argv, and run that command by hand in a terminal. The hand launch prints the real error (missing module, bad python path, permission) that the UI swallowed.

debug py3 kernel: kernel error on startup, no traceback in logs

Use this when

• JupyterLab shows kernel error with an empty traceback on startup.
• Server logs show the kernel launching and dying with no python error.
• The python3 kernel entry exists but never connects.

Not for this skill when

• The kernel starts and dies on a specific import. That leaves a traceback; debug the import.
• All kernels fail identically. Suspect the server install, not one spec.

Steps

1. Restart the server with debug logging: jupyter lab --debug. Verify: the log now shows the exact kernel launch command.
2. Inspect the spec: jupyter kernelspec list, then read kernel.json for the python3 entry. Verify: the argv[0] python path exists.
3. Run the launch command by hand: [argv-python] -m ipykernel_launcher -f [any-json]. Verify: you see the real error printed.
4. Fix what the hand launch reveals (install ipykernel into that python, fix the path, fix permissions). Verify: the hand launch stays alive.
5. Restart the server normally and launch the kernel from the UI. Verify: it connects and executes.

Variant phrasings

kernel error no traceback jupyter lab

UI phrasing. Hand-launch the kernel to get the error.

python3 kernel failed to start empty error

Spec-level phrasing. The kernelspec python is the suspect.

debug jupyter kernel startup

General phrasing. --debug plus manual launch.

Compatibility: JupyterLab 3/4, ipykernel 6.x. The hand-launch technique works for any kernelspec.

Why it happens

The UI only shows what the kernel process reported back over its channels, and a process that dies during interpreter startup reports nothing. The server log at default verbosity also skips the launch details. Running the identical command in a terminal removes both layers of silence and shows the underlying failure, which is usually a missing ipykernel in that python or a bad interpreter path in the spec.

Edge cases / pitfalls

• The kernelspec python may be a path that no longer exists after an env was deleted and recreated. Reinstall the spec.
• A kernel.json with a relative python path resolves against the server's cwd, not yours. Use absolute paths in specs.
• --debug is noisy; capture it to a file and grep for the launch line instead of reading live.
• Fixing the terminal python does not fix the kernelspec python. Always work from the spec's argv.

Provenance

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

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

Thread query: debug py3 kernel: kernel error on startup, no traceback in logs

TL;DR: An empty kernel error means the kernel process died before it could log anything, so the first job is making it talk. Start the server with --debug, find the kernelspec with jupyter kernelspec list, read its kernel.json argv, and run that command by hand in a terminal. The hand launch prints the real error (missing module, bad python path, permission) that the UI swallowed.

Not specified by the original author.

TL;DR

JupyterLab shows kernel error with nothing in the traceback when the kernel process dies before logging, which almost always means the kernelspec's python is missing, broken, or lacks ipykernel. Open jupyter kernelspec list, read the kernel.json argv, and run that exact command in a terminal. The terminal prints the real error; fix that, reinstall the spec if needed, and the Lab error clears.

kernel failed to start: 'kernel error' with empty traceback in jupyter lab

Use this when

• JupyterLab shows kernel error and the traceback panel is empty.
• The server log shows the launch attempt but no python error.
• Other kernels (or the same kernel elsewhere) work.

Not for this skill when

• The traceback is non-empty. Read it; the answer is in there.
• The kernel starts but dies later. That is a runtime crash.

Steps

1. List specs: jupyter kernelspec list. Verify: the failing kernel's spec exists.
2. Read its kernel.json and note argv[0], the python path. Verify: that path exists on disk.
3. Hand-launch: [that python] -m ipykernel_launcher -f /tmp/test.json. Verify: you see the real error (no module, bad path, permission).
4. Fix the revealed problem: install ipykernel into that python, or fix the path. Verify: the hand launch stays alive.
5. Reinstall the spec from the fixed python if the path changed. Verify: Lab launches the kernel cleanly.

Variant phrasings

jupyterlab kernel error empty traceback

Short form. The spec's python is broken.

kernel error no details jupyter lab

UI phrasing. Hand-launch reveals the error.

kernelspec broken python kernel error

The cause phrasing. Fix the spec's python.

Compatibility: JupyterLab 3/4, ipykernel 6.x. kernelspec layout is stable.

Why it happens

Lab renders whatever the kernel process reported, and a process that fails during interpreter startup reports nothing, so the panel is empty by construction. The usual underlying failures are a deleted conda env still referenced by a spec, a python path that moved, or ipykernel missing from that python. All three are invisible from the UI and obvious from a terminal.

Edge cases / pitfalls

• Deleting and recreating a conda env with the same name leaves a spec pointing at the old path. Reinstall specs after env recreation.
• The default python3 spec may resolve differently for the server than for your shell. Check the spec's absolute path, not your PATH.
• A spec with extra env vars in env can break the launch. Compare against a known-good spec.
• Fixing your shell python does not fix the spec python. Work from kernel.json outward.

Provenance

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

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

Thread query: kernel failed to start: 'kernel error' with empty traceback in jupyter lab

TL;DR: JupyterLab shows kernel error with nothing in the traceback when the kernel process dies before logging, which almost always means the kernelspec's python is missing, broken, or lacks ipykernel. Open jupyter kernelspec list, read the kernel.json argv, and run that exact command in a terminal. The terminal prints the real error; fix that, reinstall the spec if needed, and the Lab error clears.

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.