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.

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