容器退出码怎么看
退出码是最快的一条线索：它告诉你进程是怎么结束的，日志才说明为什么结束。被信号终止的退出码等于信号编号加一百二十八，因此强制终止与正常终止有明确的数值特征；容器运行时自身产生的错误码则集中在一百二十五到一百二十七之间。两者含义完全不同，先分清类型再去看日志。
基本信息
| 正常退出 | 退出码为零，一次性任务符合预期 |
|---|---|
| 应用报错 | 退出码一，需看日志里的具体异常 |
| 运行时错误 | 一百二十五到一百二十七，通常是参数、权限或命令问题 |
| 信号终止 | 信号编号加一百二十八，如强制终止与正常终止 |
| 查看方式 | 列表看状态，详情看状态字段里的退出码与是否内存超限 |
| 组合判断 | 退出码加日志加时间戳，三者一起看结论才可靠 |
典型使用场景
- 区分故障类型：先判定是应用自己退出还是被外部终止
- 定位内存问题：确认是否因超出内存上限被强制终止
- 验证优雅退出：确认收到终止信号后是否按预期收尾
- 排查启动失败：命令不存在或权限不足的退出码很有辨识度
- 核对一次性任务：以零退出码作为任务成功的判定依据
- 构建监控规则：按退出码与重启次数设置告警阈值
常见退出码
| 退出码 | 含义 | 下一步 |
|---|---|---|
| 0 | 正常退出 | 一次性任务符合预期 |
| 1 | 应用报错 | 看日志里的异常堆栈 |
| 125 | 运行时执行失败 | 检查启动参数与镜像 |
| 126 | 命令不可执行 | 检查权限或文件格式 |
| 127 | 命令不存在 | 核对启动命令与工作目录 |
| 137 | 被强制终止 | 内存超限或健康检查失败被杀 |
| 143 | 收到终止信号 | 优雅停止，通常属于正常 |
| 255 | 运行环境或脚本自身错误 | 结合上下文判断 |
核对现场
核对现场
docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Image}}" # 列表看状态
docker inspect myapp -f '{{.State.ExitCode}} {{.State.OOMKilled}}' # 退出码与内存超限
docker logs myapp --tail=100 # 退出前的输出
docker inspect -f '{{.State.StartedAt}} {{.State.FinishedAt}}' myapp # 时间线
# 退出码说明怎么死的，日志说明为什么死的退出码是结论，日志是原因：把两者与启动结束时间对齐，多数崩溃问题不需要反复重启试错就能定性。
强制终止不等于内存超限：也可能是人为清理、节点资源回收或健康检查失败导致的终止，要结合是否标记为内存超限来判断。
一百二十五到一百二十七这类错误不会产生应用日志：因为应用根本没起来，此时应该去看运行参数与镜像内容，而不是翻业务日志。
把非零退出码一律当成代码缺陷会走很多弯路：先按退出码分好类，再决定是查代码、查资源还是查运行参数。
与其他信号的配合
- 把退出码与是否内存超限放在一起判断，避免误判原因
- 结合启动与结束时间还原时间线，判断故障发生顺序
- 一次性任务的退出码是判定成功的首要依据
- 对反复出现的退出码建立告警规则，缩短发现时间
- 把退出码含义整理进运维手册，值班人员不必临场查阅
把退出码与告警结合：重启次数与退出码组成规则后，问题能在用户感知之前被系统发现，而不是靠人工巡检。