Containerd Service Keeps Crashing – Fix It Fast
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?