255 从哪来
Docker 自己定义了一组退出码：125 表示 docker run 自身失败，126 表示命令无法执行，127 表示找不到命令，128+N 表示进程被信号 N 终止（137 即 SIGKILL，常见于内存超限）。255 不在这张表里。进程退出码只有 8 位，取值范围 0 到 255，很多语言把 exit(-1)、System.exit(-1) 归一化成 255，所以 255 通常代表应用自己约定的错误，要按应用日志定位，而不是按容器故障处理。
基本信息
| 含义 | 应用自定义错误，常见于 exit(-1) 归一化 |
|---|---|
| Docker 层对照 | 125 run 自身失败；126 不可执行；127 命令不存在；128+N 被信号终止 |
| 取值上限 | 8 位，0 到 255，超出会被截断取模 |
| 事后查看 | docker inspect -f '{{.State.ExitCode}}' <容器> |
| 前台查看 | docker run --rm 之后读 shell 的 $? |
| 上游影响 | 编排器只按退出码决定是否重启，不解释 255 的含义 |
典型使用场景
- CI 里跑一次性容器做检查，用退出码决定流水线是否继续
- 排查反复重启的 Pod，先看真实退出码再决定查日志还是查资源限额
- 容器内调用 ssh 或 scp，工具自身的 255 会作为容器退出码传出
- 用 docker wait 等待容器结束，把退出码交给后续编排逻辑
- 区分应用报错与 Docker 层报错，避免排查方向从一开始就跑偏
取退出码的几种方式
取退出码的几种方式
docker run --rm app/tool:1.0 check-config # 前台执行一次性任务
echo "exit=$?" # 立刻记录退出码，--rm 已经把容器删掉了
docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <容器> # 事后取退出码与是否被 OOM 杀
docker wait <容器> # 阻塞等待结束并打印退出码
docker logs --tail 100 <容器> # 退出码只说明失败，原因在应用日志里退出码速查
| 退出码 | 含义 | 常见成因 |
|---|---|---|
| 0 | 成功 | 命令正常结束 |
| 125 | docker run 自身失败 | 参数非法、daemon 连不上、镜像拉取失败 |
| 126 | 命令无法执行 | 没有执行权限、目标不是可执行文件 |
| 127 | 找不到命令 | 命令名拼错、镜像里没装这个程序 |
| 137 | 被 SIGKILL 终止 | 内存超限被 OOM Killer 杀掉，或执行了 docker kill |
| 143 | 被 SIGTERM 终止 | docker stop 默认发送的信号 |
| 255 | 应用自定义错误 | 应用以 -1 退出、ssh 类工具连接失败 |
退出码是 8 位无符号数，应用里写 exit(256) 会被截断成 0，把失败标成成功。想让脚本区分失败原因，更可靠的做法是给不同错误分配互不相同的非零码，而不是统一用 255。
Kubernetes 只依据退出码决定是否重启，不会解释 255 的语义。Pod 反复重启时看 kubectl describe 里的 Last State 退出码，再对照应用日志和容器内存限额，137 与 255 的处理路径完全不同。
容器里跑 ssh、scp、sftp 时，OpenSSH 约定用 255 表示连接或认证失败，这个码与 Docker 无关。看到 255 先分辨是应用约定还是工具约定，再决定查应用日志还是查网络与密钥。