Docker 容器反复重启怎么办？从日志到退出码的排查方法

前言

在 Linux 云服务器上使用 Docker 部署应用时，偶尔会遇到容器启动几秒后退出，然后又自动重启的情况。

遇到这种问题，先不要急着重新创建容器。Docker 本身提供了日志、退出码和运行状态等排查信息，通常可以帮助我们缩小问题范围。

下面整理几个比较实用的命令，适用于常见的 Linux Docker 环境。

一、查看容器状态

首先执行：

docker ps -a

重点观察 STATUS 列。如果显示 Restarting，说明容器正在经历重启过程。

也可以单独查看某个容器：

docker inspect --format '{{.State.Status}}' 容器名

如果容器已经退出，或者一直处于重启状态，就需要进一步查看日志和退出原因。

二、查看容器日志

日志通常是最直接的排查入口：

docker logs --tail 100 --timestamps 容器名

这条命令会读取最近 100 行日志，并显示时间戳。

如果想实时查看新日志，可以使用：

docker logs -f --tail 50 容器名

常见的错误包括配置文件缺失、数据库连接失败、文件权限不足，以及应用启动参数不正确等。

需要注意，docker logs 主要读取容器的标准输出和标准错误。如果程序把日志写在容器内部文件中，还需要检查对应的日志文件。

三、检查退出码和 OOM 状态

可以通过 docker inspect 查看容器最近一次退出时的状态：

docker inspect --format '{{.State.ExitCode}}' 容器名
docker inspect --format '{{.State.OOMKilled}}' 容器名

常见情况：

• 退出码为 0：通常表示主进程正常结束。
• 退出码为 1：一般表示程序发生错误，具体原因需要结合日志判断。
• 退出码为 137：通常表示进程收到了 SIGKILL，但不一定是内存不足。
• OOMKilled 为 true：表示 Docker 记录到容器因内存不足而被终止。

如果怀疑内存不足，还可以查看服务器内存情况：

free -h

需要结合内存限制、系统日志和运行负载进行判断，不能只根据退出码就认定是 OOM。

四、检查自动重启策略

Docker 支持不同的重启策略，例如 no、always、unless-stopped 和 on-failure。

查看当前容器配置：

docker inspect --format '{{.HostConfig.RestartPolicy.Name}}' 容器名

如果应用本身存在启动错误，同时配置了自动重启，就可能不断重复启动失败的过程。

因此，自动重启策略只能帮助服务恢复，不能代替故障排查。

五、如果使用 Docker Compose

通过 Docker Compose 部署的应用，可以在项目目录执行：

docker compose ps
docker compose logs --tail 100

如果只想查看某个服务的日志：

docker compose logs --tail 100 服务名

这里的服务名是 Compose 配置中的服务名称，不一定与最终容器名称相同。

对于依赖数据库、Redis 等其他服务的应用，还要确认依赖服务是否已正常运行。

六、排查时的注意事项

不建议在还没有确认故障原因时，就直接删除容器、数据卷或者执行大范围清理命令。

如果容器包含数据库等重要业务，先确认数据卷挂载位置和备份情况，再决定是否重建。

另外，容器反复重启也可能与应用自身的启动逻辑有关。例如，应用要求某个环境变量必须存在，但部署时没有配置，那么单纯增加重启次数也无法解决问题。

总结

Docker 容器反复重启时，可以按照下面的顺序排查：

1. 使用 docker ps -a 查看容器状态。
2. 使用 docker logs 查看具体错误。
3. 使用 docker inspect 检查退出码和 OOM 状态。
4. 确认容器的自动重启策略。
5. 如果使用 Docker Compose，再检查相关依赖服务。

核心思路是先找到容器退出的真正原因，再有针对性地修改配置或修复应用，而不是反复重启。