容器exited后无法start，主因是cgroup子系统残留未释放，导致挂载失败；需手动卸载异常cgroup挂载、删除残留目录并重启docker服务，预防措施包括升级Docker、配置systemd驱动及使用--rm参数。
这个问题比较特殊，不是常规的“容器退出后清理不干净”，而是容器已处于 exited 状态，但后续尝试 docker start 时失败，报错常含 cgroup、mount、device or resource busy 或 failed to mount cgroup 等关键词。根本原因在于：容器虽已退出，其关联的 cgroup 子系统（尤其是 systemd、memory、pids、cpu 等控制器）未被内核完全释放，或挂载点残留，导致 docker daemon 在重启时无法重新分配或挂载所需资源。
确认是否为 cgroup 挂载残留问题
先排除常见误判——不是镜像损坏、命令错误或配置缺失，而是底层资源卡死：
- 执行
docker start失败，日志中出现类似failed to create endpoint、cannot mount cgroup、device or resource busy或open /sys/fs/cgroup/...: no such file or directory - 检查该容器是否曾使用
--cgroup-parent、--memory、--pids-limit等资源限制参数 - 运行
ls /sys/fs/cgroup/systemd/docker/（或对应 memory/cpu/pids 目录），若存在残留子目录，说明 cgroup 路径未自动清理* - 执行
cat /proc/mounts | grep cgroup | grep docker，观察是否有重复或异常挂载项（如多个相同路径的 cgroup2 挂载）
手动清理残留 cgroup 条目
Docker daemon 本身不负责强制回收内核级 cgroup 资源，需人工介入（仅限 Linux 主机，且需 root 权限）：
- 停止 Docker 服务：
sudo systemctl stop docker - 查找并卸载残留 cgroup 挂载（重点检查 cgroup2 和 legacy 混合环境）：
sudo umount $(grep "cgroup.*docker" /proc/mounts | awk '{print $2}') 2>/dev/null || true - 删除残留 cgroup 目录（谨慎操作，只删明确属于该容器的）：
sudo rm -rf /sys/fs/cgroup/*/docker/*
（替换a1b2c3d4e5f6） - 可选：清空所有 docker 相关 cgroup 子树（适用于批量故障）：
sudo find /sys/fs/cgroup -path "*/docker/*" -mindepth 1 -delete 2>/dev/null || true - 重启 Docker：
sudo systemctl start docker
避免再次发生的关键配置
这不是偶发 bug，而是特定内核 + Docker 组合下的已知边界问题（尤其在较老内核如 5.4 或启用 systemd-cgroups 驱动时）。预防比修复更重要：
- 升级 Docker 到 v24.0+ 并确保使用
systemd作为 cgroup 驱动（检查docker info | grep "Cgroup Driver"，应为systemd） - 在
/etc/docker/daemon.json中显式配置：{"cgroup-parent": "docker.slice", "default-runtime": "runc"}，避免容器直接挂在根 cgroup 下 - 禁用非必要资源限制：若无需精细控制，去掉
--memory、--cpus、--pids-limit等参数，减少 cgroup 控制器绑定深度 - 对一次性任务容器，加
--rm参数，让退出后自动清理元数据与关联资源（包括 cgroup 清理更积极）
验证与兜底方案
清理后不要直接 start，先做最小验证：
- 运行一个极简容器测试 cgroup 可用性：
docker run --rm alpine echo ok，成功则说明基础挂载正常 - 对原问题容器，先
docker rm -f彻底移除（exited 容器无运行态，-f安全），再用相同命令重建启动 - 若仍失败，临时切换 cgroup 驱动为
cgroupfs（修改daemon.json加"exec-opts": ["native.cgroupdriver=cgroupfs"]，重启 docker），用于快速恢复业务（不推荐长期使用）
