Docker 守护进程崩溃后容器没有自动恢复怎么办

从 docker.service 日志确认健康检查崩溃现场，保留证据后恢复 Compose 服务，并核对重启策略与业务健康

直接答案：如果业务突然中断、容器显示 Exited (0)，而 Docker 服务的启动时间比主机运行时间新，先不要把问题归因于应用。先读取 docker.service 日志；若同一时间出现 unexpected fault、SIGSEGV、CommitInMemory 和 handleProbeResult，现场与 Moby 上游 2026 年 9 月报告的 Docker Engine 29.7.2 健康检查后台任务崩溃相符。保存版本、日志和容器状态后，从原 Compose 项目目录执行 docker compose up -d 恢复，再逐个验证健康状态和业务入口。

上游 Issue 目前仍未给出确定根因、稳定复现方法或已发布修复版本。因此，不能把任意 Exited (0) 都写成 Docker 缺陷，也不能承诺升级某个版本必然修复。本文的目标是帮你区分“应用退出”和“守护进程崩溃后未恢复”，并建立可回退的恢复步骤。

先用只读命令确认是不是 dockerd 崩溃

以下命令适用于使用 systemd 管理 Docker 的 Linux 主机。它们不会启动、删除或修改容器。日志时间范围应覆盖业务中断前后；不要把仓库凭据、环境变量和完整容器配置贴到公开工单。

uptime -s
systemctl show docker.service -p ActiveEnterTimestamp -p ExecMainStartTimestamp -p NRestarts
systemctl status docker.service --no-pager
journalctl -u docker.service --since "2 hours ago" --no-pager
docker version
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'

如果主机已经运行多天，而 ExecMainStartTimestamp 只有几分钟，并且日志在中断时出现 fatal error 或 SIGSEGV，说明 Docker 守护进程确实重新启动过。上游报告的特征栈包含 Container.CommitInMemory、handleProbeResult 和 monitor。若日志只有正常的 Stopping Docker，应继续查系统升级、人工操作或自动化任务；若 Docker 服务时间未变化，则优先检查应用日志和健康检查本身。

检查结果	更可能的原因	下一步
docker.service 新启动，日志命中 SIGSEGV 与健康检查栈	与 Moby #53734 现场相符	保存证据，恢复服务并持续监控
docker.service 新启动，但日志是正常 stop/start	系统升级、人工或自动任务重启	查 apt、dnf、运维任务与变更记录
docker.service 未重启，单个容器 Exited	应用退出、资源不足或健康检查之外的问题	读取容器日志与 State 字段
容器仍 Up，但业务不可用	端口、依赖、网络或应用健康异常	按 unhealthy 与网络链路排查

保存哪些证据，避免恢复后查不到

先记录 Engine 服务端版本、Docker 服务日志、退出容器状态和 Compose 项目名称。不要先执行 docker system prune、删除容器或清空日志；这些操作会减少取证信息，并可能带来镜像重拉和数据误删风险。

docker compose ls -a
docker inspect --format '{{.Name}} status={{.State.Status}} exit={{.State.ExitCode}} finished={{.State.FinishedAt}} restart={{.HostConfig.RestartPolicy.Name}} health={{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}}' $(docker ps -aq)
journalctl -u docker.service --since "2 hours ago" --no-pager > docker-service-incident.log

ExitCode=0 只表示容器主进程记录为正常退出，不证明业务主动、完整地关闭。若多个不相关容器在相近时间一起变为 Exited (0)，而 daemon 同时崩溃，应把守护进程事件放在更高优先级。保存的日志文件可能包含主机名、镜像名和路径，外发前需要脱敏。

怎样安全恢复 Compose 服务

恢复动作会启动容器并可能重新执行数据库迁移、队列消费或定时任务。先确认数据库卷、绑定目录和外部依赖仍存在；有主从或集群的服务应先确认不会造成双写。找到原来的 Compose 文件目录后，先检查将要应用的配置。

docker compose config --quiet
docker compose ps -a
docker compose up -d
docker compose ps

config --quiet 没有输出且退出码为 0，表示 Compose 文件可以解析，但不代表业务一定安全。up -d 可能重建与当前配置不一致的容器；因此必须在原项目目录执行，并先备份最近修改过的 Compose 文件和环境文件。不要使用 down -v，其中 -v 可能删除命名卷。

如果找不到项目目录，不要凭镜像名临时拼一份配置。先用 docker compose ls -a 获取项目名和配置文件路径；若旧版本没有显示路径，再从部署记录、systemd 单元或 CI 配置中恢复原始文件。原配置无法确认时，只恢复无状态前端也可能造成错误写入，应该先保持服务停止并人工核对。

为什么 restart: unless-stopped 不能当作高可用保证

Docker 官方文档说明，重启策略主要处理容器退出；守护进程自身不可用时，容器行为还受 daemon 重启、live-restore 和停止状态判断影响。Moby #53734 的报告现场正是 systemd 数秒内拉起 dockerd，但原先运行且配置 unless-stopped 的容器仍保持停止。因此“已经配置重启策略”不能替代外部可用性监控和恢复演练。

live-restore 能在部分 daemon 不可用场景保持 Linux 容器运行，但有明确条件和限制，也不能证明这次健康检查崩溃一定不会影响业务。启用前先阅读当前 Docker 版本文档，并在非生产节点演练 daemon reload、restart 和升级；不要在故障现场临时修改后就宣称问题解决。

恢复后怎样验收

先看容器状态，再检查健康检查详情、监听端口和真实业务入口。把示例中的服务名和 URL 替换为实际值。

docker compose ps
docker inspect --format '{{json .State.Health}}' <CONTAINER_NAME>
ss -lntp
curl -fsS --max-time 10 https://<YOUR_DOMAIN>/health

合格结果是：预期服务均为 Up；有健康检查的容器最终为 healthy；宿主机监听端口与配置一致；从用户入口访问返回预期状态。只有容器 Up、但 health 接口仍失败时，不要反复重启 dockerd，应检查应用依赖、数据库、DNS、证书和反向代理。

建立至少一条外部告警：Docker 服务重启次数增加、关键容器停止或业务健康接口失败时通知值班人员。外部探测必须从容器和宿主机之外发起，否则 daemon 崩溃时监控本身也可能消失。

是否要禁用健康检查或立即升级

不要因为单个未确认 Issue 就全站删除健康检查。健康检查仍用于发现应用不可用，也是编排和负载均衡判断的重要信号。若现场反复命中相同崩溃栈，可在维护窗口把受影响工作负载迁移到备用节点，减少健康检查频率或隔离可疑服务作为临时诊断，但每项变化都要保存原配置并验证业务。

升级前先查看 Docker Engine 发布说明是否明确包含对应修复；没有明确依据时，只能把升级视为常规风险控制，不能写成确定修复。升级可能重启 daemon，应先备份配置、确认卷与 Compose 文件、准备包版本回退，并逐台处理。

相关基础步骤可继续阅读 Docker Compose 容器 unhealthy 排查、Docker Compose 生产部署、systemd 服务反复重启排查和 Linux OOM Killer 排查。这些页面分别处理应用健康、部署基线、服务重启和内存终止，不替代本文对 dockerd 崩溃日志的判断。

官方与上游来源

• Moby 上游 Issue #53734：Docker 29.7.2 健康检查监控中的 SIGSEGV 现场、堆栈和容器未恢复现象。
• Docker 官方文档：自动启动容器：重启策略的行为与限制。
• Docker 官方文档：live restore：daemon 不可用期间保持容器运行的条件与边界。
• Docker 官方文档：docker compose up：创建、重建与启动服务的行为。

来源最后核验：2026-10-08。本稿未发现需要补充确认的黑鲨云业务事实；Moby #53734 的根因和修复版本仍未确认，生产内容简报与精确 intent_key 必须在晚间发布前复核。