退出码总览是什么
容器退出码是排障的第一条线索：它先告诉你失败发生在哪一层——是应用自己退出、是 Docker 引擎拒绝执行、还是进程被信号终止。约定来自 shell：128 加信号编号表示被信号终止，因此 137 是 128+9（SIGKILL）、143 是 128+15（SIGTERM）。把退出码归类之后，判断该去看 daemon 日志还是应用日志就有了方向。
基本信息
| 查看方式 | docker ps -a 的 STATUS 列，或 docker inspect -f '{{.State.ExitCode}}' 容器 |
|---|---|
| 关键字段 | .State.ExitCode / .State.OOMKilled / .State.Error / .State.StartedAt |
| 分层含义 | 0-1 应用层；125-127 Docker 层；128 以上信号层；255 应用约定 |
| 事件流 | docker events --filter container=名称 --since 1h |
| 平台说明 | Linux 容器语义；Windows 容器退出码含义另按系统约定 |
退出码对照
| 退出码 | 含义 | 常见原因 |
|---|---|---|
| 0 | 正常退出 | 一次性任务完成 |
| 1 | 应用错误 | 程序自身异常退出，Docker 未定义该码 |
| 125 | docker run 自身失败 | daemon 报错、参数非法 |
| 126 | 命令无法执行 | 权限不足、文件不是可执行格式 |
| 127 | 找不到命令 | 命令不存在或 PATH 不对 |
| 137 | 128+9：被 SIGKILL | 内存超限被 OOM 杀、stop 超时强杀、docker kill |
| 139 | 128+11：段错误 | SIGSEGV，多为二进制或依赖不匹配 |
| 143 | 128+15：SIGTERM | 被正常停止或进程自行处理退出 |
| 255 | 应用自定义 | exit(-1) 之类的约定 |
典型使用场景
- 容器反复重启时先看退出码判断是应用崩溃还是被系统杀掉
- 排查一次性任务失败：区分业务失败与启动命令写错
- 识别 OOM：137 配合 OOMKilled 字段与宿主日志确认
- 分析编排平台反复拉起容器的根因
- 给监控告警配置退出码分类，减少无效告警
定位示例
定位示例
# 先看整体：哪些容器退出了、状态与退出码是什么
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'
# 再看细节：退出码、是否 OOM、引擎侧错误信息
docker inspect -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} err={{.State.Error}}' web
# 信号类退出码减 128 得到信号编号，137 对应 9
# 应用层退出（1/255）看业务日志，Docker 层退出（125-127）看命令与参数
docker logs --tail 200 web
docker events --filter container=web --since 1h同一个码可能有不同原因：137 既可能是内存超限，也可能是 docker stop 宽限期结束后被强杀。判定要点是比较 OOMKilled 字段、内存限额与停止时间点，而不是看到 137 就认定内存问题。
退出码 0 也不代表任务成功：脚本里最后一条命令成功就会返回 0，中间步骤失败被忽略的情况要靠设置 shell 严格模式来暴露。