Docker容器退出码137且OOMKilled为false故障排查求助

问题解答 #

1. 服务全部退出的最可能原因 #

Exit 137本质是进程收到SIGKILL信号被强制终止，结合你描述的所有容器几乎同时退出的特征，最常见的两个诱因：

• 你执行docker-compose up时未加-d后台运行参数，当前终端会话断开时，系统会给前台运行的docker-compose进程发送SIGHUP信号，docker-compose会终止所有它管理的容器，完全匹配你观察到的±0.05秒内集中退出的现象。
• 你的loader服务未显式指定entrypoint，继承了Dockerfile中python -m mysupercoolsystem的启动逻辑，如果该代码没有常驻运行的逻辑，执行完任务就会主动退出，部分旧版本docker-compose在未指定特殊参数时，若关联的服务中有一个容器主动退出，也会触发其他容器批量终止。

2. 进一步排查的措施 #

• 复现测试：加-d参数后台启动服务，主动断开终端后重新连接，检查容器状态是否正常。
• 单独验证loader服务：执行docker run --rm hub.nic.com/nicecompany/mysupercoolsystem，观察服务是否会执行完直接退出，确认退出码。
• 检查docker daemon运行记录：执行systemctl status docker，确认docker服务的启动时间是否早于容器退出时间，排除daemon重启导致容器被终止的可能。

3. 需要额外检查的日志 #

• Docker daemon日志：执行journalctl -u docker.service --since "2021-11-13 10:00:00" --until "2021-11-13 11:00:00"，查看指定时间窗口内docker daemon的运行异常记录。
• 系统内核日志：执行journalctl -k --since "2021-11-13 10:00:00" --until "2021-11-13 11:00:00"，排查内核层面是否有进程信号、资源限制相关的记录。
• 单个容器的运行日志：分别执行docker logs 容器ID查看每个容器退出前的最后输出，重点查看loader服务的日志，确认是否是它先退出触发的连锁反应。

4. 配置restart: unless-stopped后的补充排查方式 #

• 通过docker inspect 容器ID查看容器State字段的重启时间、退出码变化，判断重启的频率和触发规律。
• 执行docker events监听容器生命周期事件，可以捕获到容器接收的信号、停止、重启等全量事件，定位终止信号的来源。
• 查看cgroup内存统计：访问/sys/fs/cgroup/memory/docker/容器ID/memory.oom_control，查看oom_kill计数，排查是否有cgroup层面触发的OOM（这类OOM可能不会更新docker inspect中的OOMKilled标记）。
• 若系统开启了auditd服务，可执行ausearch -m kill -ts 2021-11-13 10:30，查询是否有其他进程主动发送kill信号给容器进程。

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