Docker容器退出码为0且启动秒退，如何恢复及排查？

一、排查容器退出原因的可行方法 #

• 重新查看容器历史日志：docker logs 命令支持查看已退出容器的日志，无需容器处于运行状态。执行 docker logs --tail 200 <容器ID> 查看最近200行日志，或 docker logs <容器ID> 查看完整日志，大概率能找到进程正常退出的原因。
• 启动容器进入交互式调试：
  • 基于原镜像调试：执行 docker run --rm -it --entrypoint sh <容器镜像名>，直接进入容器shell，手动执行原启动命令，观察执行过程中的输出和行为。
  • 针对已有容器：先将容器提交为临时镜像 docker commit <容器ID> temp-image，再用上述交互式命令启动临时镜像调试。
  • 强制启动容器并附加终端：docker start -a -i <容器ID>，容器启动时会将输出直接打印到当前终端，即使很快退出也能捕获关键信息。
• 检查容器启动命令配置：
  • 查看容器的ENTRYPOINT：docker inspect --format='{{.Config.Entrypoint}}' <容器ID>
  • 查看容器的CMD：docker inspect --format='{{.Config.Cmd}}' <容器ID>
    确认启动命令是否为一次性执行任务（比如仅执行一个配置脚本就结束），这类场景下进程正常完成后自然会返回退出码0并终止。
• 跟踪进程系统调用：启动容器时用 strace 跟踪主进程的系统行为，执行 docker run --privileged -it --entrypoint strace <镜像名> <原启动命令>，通过系统调用日志判断进程为什么会正常退出。
• 排查宿主机基础环境：
  • 检查磁盘空间：df -h，若磁盘满可能导致进程无法写入文件提前终止（部分进程会返回0）。
  • 检查内存状态：free -m，内存不足可能触发OOM，但退出码0的概率较低，仍可排查确认。

二、关于强制容器不返回退出码0的说明 #

无法强制容器不返回退出码0，因为退出码是容器内主进程的原生返回值，0代表进程正常终止。强行修改退出码没有实际意义，反而会掩盖真实问题。

若只是临时让容器保持运行状态用于调试，可以修改启动命令，在原命令后追加阻塞进程的指令，比如：

• 原启动命令为 ./app.sh，修改为 ./app.sh && tail -f /dev/null
• 或直接替换启动命令为 sleep infinity

但这只是临时调试手段，不能解决根本问题，建议优先通过上述排查方法找到进程正常退出的原因（比如启动逻辑设计为一次性任务、依赖服务未就绪导致进程主动退出等）。

内容的提问来源于stack exchange，提问作者DI7