Docker容器启动异常：创建后无法运行且5分钟后被终止
2026-6-21
问题解答
1. 是否有人遇到过此类情况？
有不少开发者碰到过类似问题，常见触发场景包括：系统内核更新导致cgroup资源管理兼容问题、Swarm集群重启后节点状态异常、系统资源耗尽触发OOM Killer、Docker服务的systemd配置被修改引入资源限制等。
2. 存在哪些操作失误？
- 盲目执行
rm -rf /var/lib/docker重置Docker，未提前备份容器卷、镜像等关键数据，也没先排查核心问题根源，属于过度操作 - 重启机器后，未先验证基础Docker功能（比如单容器长期运行），直接部署复杂栈服务，跳过了分层排查步骤
- 未检查系统层面的资源限制（如内存、磁盘、CPU配额），也没排查Swarm集群的节点健康状态，就判定是Docker本身的问题
- 容器栈部署失败后，未先查看Swarm服务的具体错误日志，直接清理容器，丢失了关键排查信息
3. 从该情况中能学到什么？
- 分层排查原则：遇到问题先从系统层（资源、内核、systemd）→Docker基础功能→Swarm集群→容器栈逐步排查，不要直接跳级重置
- 备份优先：定期备份Docker的
/var/lib/docker/volumes（业务数据）和容器配置文件，避免重置后数据丢失 - 验证前置：系统重启或更新后，先运行简单测试容器（如
sleep infinity）验证基础功能正常，再部署生产服务 - 日志依赖：Docker服务日志、系统内核日志（dmesg）、Swarm服务日志是排查问题的核心依据，不要忽略
4. 如何进一步排查问题？
- 检查系统资源与OOM Killer：
- 执行
free -h查看内存剩余，df -h检查磁盘空间（尤其是/var/lib/docker所在分区） - 执行
dmesg | grep -i oom，确认是否有进程被OOM Killer终止（状态码137通常关联内存不足）
- 执行
- 排查Docker服务日志：
- 实时查看Docker日志：
journalctl -u docker.service -f，重点找容器创建失败、资源分配失败的报错信息
- 实时查看Docker日志：
- 检查Swarm集群状态：
- 执行
docker node ls确认节点状态为Active，若为Down则重新加入集群 - 执行
docker service ps wp查看栈服务的任务状态，获取具体失败原因（如镜像拉取失败、卷挂载错误）
- 执行
- 验证systemd资源限制：
- 查看Docker服务的systemd配置：
systemctl show docker.service | grep -E '(MemoryLimit|CPUQuota)'，确认是否有不合理的资源限制 - 检查
/etc/systemd/system/docker.service.d/下的自定义配置文件，是否有新增的限制规则
- 查看Docker服务的systemd配置：
- 测试基础容器运行：
- 启动无Swarm的长期运行容器：
docker run -d --name test-alpine alpine sleep 3600 - 每隔几分钟执行
docker inspect test-alpine查看状态，同时监控dmesg和系统日志，确认是否被终止及原因
- 启动无Swarm的长期运行容器：
5. 如何恢复系统稳定运行？
- 解决容器5分钟被终止问题：
- 若为OOM Killer导致：增加服务器内存，或者调整Docker的默认资源限制（在
daemon.json中设置"default-ulimits": {"memlock": -1}） - 若为systemd资源限制：修改
/etc/systemd/system/docker.service或对应配置文件，移除MemoryLimit等限制参数，执行systemctl daemon-reload && systemctl restart docker
- 若为OOM Killer导致：增加服务器内存，或者调整Docker的默认资源限制（在
- 修复Swarm栈部署异常：
- 先清理旧服务：
docker stack rm wp - 检查
docker-compose.yml配置：确认镜像地址可访问、卷挂载路径权限正确、网络配置无冲突 - 若Swarm节点状态异常：执行
docker swarm leave --force退出集群，再重新初始化docker swarm init，随后重新部署栈
- 先清理旧服务：
- 恢复业务数据：如果之前重置了
/var/lib/docker，从备份恢复卷数据，或重新导入网站数据（如WordPress的数据库和文件） - 验证稳定性：运行测试容器观察至少10分钟，确认无自动终止后，再部署生产网站栈，监控容器状态至正常运行
6. 问题最初为何会出现？
最可能的几个原因：
- 系统内核更新：CoreOS重启后可能自动更新了内核，新内核的cgroup资源管理逻辑变化，导致Docker容器的资源分配异常，触发OOM Killer或启动失败
- Swarm集群状态不一致：机器重启后，Swarm节点的集群状态未正常同步，导致服务调度失败，容器始终处于
created状态 - 磁盘资源不足：重启后磁盘空间被其他进程占用，导致Docker无法为容器分配存储资源，创建容器失败
- systemd配置变更：CoreOS的自动更新可能修改了Docker的systemd服务配置，新增了内存、CPU等资源限制，导致容器无法正常运行或被强制终止
内容的提问来源于stack exchange，提问作者kklepper
相关产品推荐
相关产品推荐
