agent failed to set the kernel spec in the scheduled container, kernel error

TL;DR

A container built without a kernel spec (or with a spec pointing at a build-time path) fails at kernel launch with 'kernel error' and no useful message. Bake the spec into the image: install ipykernel in the image's python, run python -m ipykernel install --prefix=/usr/local --name [env] during the build, and verify the spec's argv is an absolute path that exists in the final image. Test kernel launch inside the built container before shipping.

agent failed to set the kernel spec in the scheduled container, kernel error

Use this when

• Kernel launch fails inside a scheduled container with an empty error.
• The container was built without ipykernel or without a spec install.
• It works outside the container.

Not for this skill when

• The kernel launches but the notebook fails. That is a notebook or env bug.
• The container itself does not start. That is an image problem.

Steps

1. Inspect the image: run it and check jupyter kernelspec list. Verify: the expected spec exists.
2. Read the spec's kernel.json argv. Verify: the python path is absolute and exists in the image.
3. Fix the Dockerfile: install ipykernel and install the spec with --prefix during build. Verify: the build log shows the install.
4. Launch a kernel inside the container: python -m ipykernel_launcher -f /tmp/t.json. Verify: it stays alive.
5. Run the scheduled command in the container. Verify: end-to-end success.

Variant phrasings

container kernel spec missing

Short form. Bake the spec into the image.

docker jupyter kernel error

The symptom phrasing. Check the spec argv.

kernelspec absolute path container

The fix phrasing. Absolute paths survive the build.

Compatibility: Docker/OCI containers, ipykernel 6.x. The bake-during-build rule is universal.

Why it happens

Kernel specs are installed per-python and per-prefix, and container builds that pip-install ipykernel but never run the spec install leave the image with the package but no registered kernel. Worse, a spec installed at build time with a relative or build-only path breaks in the final image. The kernel launch then fails with the classic empty error because the process cannot even start.

Edge cases / pitfalls

• Multi-stage builds can drop the spec if it was installed in the builder stage. Install in the final stage.
• --user installs go to a home dir that may not exist or differ at runtime. Use --prefix or --sys-prefix deliberately.
• The runtime user must be able to read the spec files. Check permissions in the final image.
• Test as the runtime user, not root. Root's paths and permissions differ.

Provenance

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