failed to create shim task: containerd could not start the process that supervises the container

containerd runs a shim process per container to supervise it. When the shim cannot be created, no container starts, and the wrapped error after the phrase names the real reason.

Applies to: Clusters using containerd

What it means

containerd does not supervise containers directly. It starts a small shim process for each one, which owns the container's lifecycle and survives containerd restarts. failed to create shim task means that step failed, and like the OCI wrapper it carries the underlying error as a suffix. In practice the causes cluster around node-level resource exhaustion and cgroup problems: no memory to fork the shim, no PIDs available, a cgroup path that cannot be created, or a filesystem that is full or read-only. It is therefore more often a statement about the node's health than about the pod.

Most common causes

• The node is out of memory, so the shim cannot be forked.
• PID exhaustion on the node.
• A cgroup path that cannot be created, often after a cgroup driver mismatch or a cgroup v1 to v2 transition.
• A full or read-only filesystem where containerd stores its state.
• The OCI runtime binary being missing or not executable on the node.
• containerd's state directory being corrupted after an unclean shutdown.
• Too many open files at the node level, so the shim cannot allocate descriptors.

How to diagnose it

1. Read the suffix after the phrase — as with the OCI wrapper, that is the actual error.
2. Check node resources: memory, PIDs, and disk. kubectl describe node NODE for conditions, then the node directly.
3. Read containerd's log: journalctl -u containerd -n 200.
4. Check the cgroup driver agreement between the kubelet and containerd.
5. Check file descriptor limits for the containerd service: cat /proc/$(pidof containerd)/limits.
6. Check whether the node's cgroup version changed recently, for example after a host operating system upgrade.

How to fix it

1. Relieve the node's resource pressure — memory, PIDs, disk, or descriptors, whichever the suffix implicates.
2. Align the cgroup driver between the kubelet and containerd, and restart both.
3. Raise the file descriptor limit on the containerd service unit if it is the constraint.
4. Restart containerd to clear a corrupted transient state, and drain the node first if the workload cannot tolerate it.
5. Replace the node if the same failure recurs after a restart, since it usually indicates something persistent.

Notes

The shim is what allows containers to keep running across a containerd restart. That design means a shim failure is a node-level problem rather than a container-level one, and rescheduling the pod elsewhere usually works immediately — which is a useful signal that the node is the fault.

Related

• OCI runtime create failed — The low-level runtime refused to create the container
• PIDPressure — The node is running out of process IDs

Sources

• Kubernetes documentation — Container Runtime Interface
• containerd CRI plugin configuration
• containerd — Getting Started