containerd崩溃时容器失去生命周期管理，需通过ss、ps、crictl验证grpc监听与进程状态，查journalctl定位panic/oom等日志，检查cgroup、inotify、runc兼容性及磁盘元数据，清理shim、socket和临时目录后重启。
containerd 崩溃时，所有容器会瞬间失去生命周期管理能力——docker ps卡住、kubectl get pods超时、ctr命令无响应，这不是容器问题，是运行时底座崩了。
确认 containerd 进程是否真挂了
别只信 systemctl status containerd 的“active (running)”——它可能只是 systemd 认为服务还在，实际 gRPC 监听已失效。
- 执行
sudo ss -tlnp | grep :6060（默认 debug 端口）或sudo ss -tlnp | grep :10010（CRI 默认端口），若无输出，说明 containerd 主进程未监听或已退出 - 检查
ps aux | grep containerd：正常应有containerd主进程 + 若干containerd-shim；若只剩 shim 且主进程消失，就是崩溃了 - 直接调用 CRI 接口验证：
sudo crictl version，返回FATAL: unable to determine runtime version或连接拒绝，基本可断定 containerd 已不可达
查 journalctl 日志定位崩溃前最后一刻
containerd 崩溃往往不打印堆栈，但会在退出前留下关键线索，重点盯三类日志：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行
sudo journalctl -u containerd -n 200 --no-pager | grep -E "(panic|segfault|fatal|OOM|signal.*terminated|failed to start)" - 若看到
runtime/cgo: pthread_create failed: Resource temporarily unavailable，说明系统线程数打满（/proc/sys/kernel/threads-max耗尽） - 若出现
failed to mount overlay: invalid argument且紧随其后是exit status 1，大概率是内核版本与 runc 不兼容，或 cgroups v2 配置冲突 - 注意时间戳对齐：崩溃时刻的前 5 秒内是否有大量
task delete或shim disconnect日志，这可能是连锁雪崩起点
检查底层依赖是否被破坏
containerd 不是孤立运行的，它的崩溃常由下层资源枯竭或内核行为异常触发：
- 确认 cgroup 状态：
mount | grep cgroup，若输出为空或只有cgroup2fs但/proc/sys/kernel/cgroup_disable含memory，说明 memory controller 被禁用，runc 创建容器必失败 - 检查 inotify 限制：
cat /proc/sys/fs/inotify/max_user_watches，低于 524288 时，containerd watch snapshot 变更易触发 fd 耗尽并静默退出 - 验证 runc 兼容性：
sudo runc --version输出的 commit 是否在 containerd 官方 tested list 内（如 containerd v1.7.13 要求 runc v1.1.12）；禁止 PATH 中存在多个 runc 版本 - 检查磁盘元数据损坏：
sudo ls -la /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/，若大量目录权限为??????????或ls: cannot access，说明底层文件系统已损坏，containerd 会反复 open 失败后 panic
恢复服务前必须清理的残留状态
直接 systemctl start containerd 很可能失败，因为崩溃前未释放的锁或僵尸 shim 会阻塞重启：
- 先杀光 shim：
sudo pkill -f 'containerd-shim.*-namespace moby'（K8s 场景用k8s.io） - 清空 runtime socket：
sudo rm -f /run/containerd/containerd.sock和/run/containerd/containerd.sock.ttrpc - 删除临时状态目录（非数据目录）：
sudo rm -rf /run/containerd/io.containerd.runtime.v2.task/moby/* - 最后再
sudo systemctl start containerd；启动后立刻跑sudo ctr -n moby containers list验证是否可连
真正难处理的不是崩溃本身，而是崩溃后 shim 进程僵死却不报错——它们还占着容器 PID namespace 和 cgroup path，导致新 containerd 启动后一创建 task 就被旧 shim 抢占资源，现象就是“刚启就又挂”。这种 case 必须手动 kill -9 所有 shim，不能依赖 graceful shutdown。
