Containerd Service Keeps Crashing – Fix It Fast

Linux & Unix Intermediate 👁 10 views 📅 Jun 24, 2026

Containerd crashing? Start with checking disk space and logs. If that's clean, it's likely a config or kernel issue. Here's the fix order I use.

Containerd Service Crash – Where to Start

Containerd crashes for a few reasons. Most common? Disk full or the log file blew up. I've seen it happen on Ubuntu 20.04 and CentOS 7 alike. The service just dies, and systemd shows a vague "failed" status. Don't panic. We'll go from easiest to hardest.

Before you start, have root access or sudo. You'll need it for every step here.

Step 1: The 30-Second Check – Disk Space and Logs

This is the one that gets me every time. Containerd won't start if /var/lib/containerd or /var/log is full. Run this:

df -h /var/lib/containerd /var/log /

If any of those show 100% or near 100% usage, that's your culprit. Free up space. Delete old logs in /var/log first. Then check if containerd's own log is huge:

sudo ls -lh /var/log/containerd/

If you see a file like containerd.log over a few GB, truncate it:

sudo truncate -s 0 /var/log/containerd/containerd.log

Now try restarting containerd:

sudo systemctl restart containerd
sudo systemctl status containerd

If it stays up for 10 seconds, you're done. This fixes maybe 40% of crashes. If not, move on.

Step 2: Moderate Fix (5 minutes) – Check Config and Systemd

Still crashing? The config file might have a syntax error or a bad option. Containerd's config is at /etc/containerd/config.toml. Check for obvious typos. I once spent an hour because someone added a trailing comma in a TOML array.

Test the config with:

sudo containerd config dump

If it fails with an error, you'll see the line number. Fix it. Most common mistakes: a missing " on a path, or a bad plugin configuration.

Next up – check systemd limits. Containerd often hits the open file limit. Run:

sudo systemctl show containerd | grep -i limit

If LimitNOFILE is something low like 1024, increase it. Create a drop-in file:

sudo mkdir -p /etc/systemd/system/containerd.service.d
sudo tee /etc/systemd/system/containerd.service.d/limits.conf <

That works for most distros. Try that and see if the crash stops.

Step 3: Advanced Fix (15+ minutes) – Kernel Bugs, OOM, and runc Issues

If nothing above worked, we're looking at deeper stuff. First, check the kernel log for OOM kills:

sudo journalctl -k | grep -i oom
sudo dmesg | grep -i containerd

If you see oom-killer or Out of memory near containerd, the system is killing it because of memory pressure. This happens on low-memory VMs running multiple containers. Easiest fix: add swap or reduce memory limits in containerd's config. In config.toml, look for the [plugins."io.containerd.grpc.v1.cri".containerd] section and set default_runtime to something lighter like runc if it's not.

Another common cause – a buggy kernel version. I've seen containerd crash on kernel 5.4.0-26 on Ubuntu 20.04. Check your kernel:

uname -r

If you're on an older kernel, update it. For Ubuntu:

sudo apt update && sudo apt upgrade linux-image-generic
sudo reboot

For CentOS/RHEL 7 or 8, a kernel update fixed it for me once:

sudo yum update kernel -y
sudo reboot

Finally, check if runc is the problem. Containerd uses runc to run containers. If runc has a bug, containerd looks dead. Test runc directly:

sudo runc --version
sudo runc list

If runc list hangs or errors, update runc:

# For Ubuntu/Debian
sudo apt install runc
# For CentOS/RHEL
sudo yum install runc

If you're using Docker on top of containerd, also try restarting Docker: sudo systemctl restart docker. Sometimes the Docker daemon holds a lock that blocks containerd.

One More Thing – Check System Resources

If containerd still crashes after all this, check /var/log/syslog or /var/log/messages for hardware errors. I once had a bad RAM stick that only triggered when containerd tried to allocate memory for a container. Run sudo memtester or mcelog if you have it. Rare but real.

If you're on Kubernetes and using k3s, there's a known issue where containerd crashes because of a race condition with the kubelet. In that case, the fix is to update k3s to the latest patch.

That's it. Start with the disk check, then config, then kernel. 90% of the time you're done in 5 minutes or less.

Was this solution helpful?