退出码判读是什么
退出码是判断命令成败的基本信号，但在批量执行里容易被两层因素遮蔽。第一层是传输工具自身的返回码会覆盖远端命令的返回码，把连接失败与业务失败混在一起；第二层是管道的退出码默认只取最后一个命令，前面的命令失败不会体现出来。因此判读时需要区分连接层与业务层、开启管道失败传播或读取管道内各命令的状态，并注意不同工具的非零含义并不统一——有些工具把无匹配或无变更也返回非零。
基本信息
| 通用约定 | 0 表示成功，非零表示失败；大于 128 通常表示被信号终止 |
|---|---|
| 常见遮蔽 | 传输工具返回连接失败码；管道默认取最后命令的退出码 |
| 应对手段 | 开启管道失败传播、读取管道各段状态、连接层与业务层分开统计 |
| 判读要点 | 退出码要与输出（尤其标准错误）交叉判断 |
典型使用场景
- 批量执行后统计成功与失败主机数量
- 需要区分连不上与命令执行失败两种不同情况
- 管道命令中间一步失败需要被及时发现
- 工具把无匹配或无变更也返回非零，需要单独处理
- 自动化流程依据退出码决定继续、重试还是停止
退出码判读写法
退出码判读写法
if ssh -n -o BatchMode=yes "$h" 'systemctl is-active app'; then
echo "$h ok"
else
rc=$? # 255 通常是连接或认证失败，其余多为远端命令退出码
printf '%s rc=%s\n' "$h" "$rc"
fi
set -o pipefail # 管道中任一环节失败，整体返回非零
tar -cf - /data | gzip > /backup/data.tar.gz
tar -cf - /data | gzip > /tmp/x.tar.gz; echo "${PIPESTATUS[@]}" # bash：读取各段状态
grep -q pattern file || true # 无匹配不算失败的情形按工具语义单独处理退出码与含义
| 退出码 | 常见含义 | 注意点 |
|---|---|---|
| 0 | 成功 | 部分工具即使无变更也返回 0，需看输出 |
| 1 | 一般性失败 | 多数工具的默认失败码 |
| 2 | 用法或参数错误 | 常见于命令行参数解析失败 |
| 126 / 127 | 不可执行、命令未找到 | 常见于 PATH 与权限问题 |
| 130 | 被中断信号终止 | 人工中断或信号传递 |
| 255 | 传输层连接或认证失败 | 必须与远端业务失败分开统计 |
退出码只反映进程如何结束，不代表结果符合业务预期：很多命令执行成功但结果错误。批量场景应把退出码与关键输出（特定字段或状态查询）结合，才能判断变更是否真的生效。
远程执行时，中继层（传输工具、容器运行时、调度器）的返回码可能覆盖被调用程序的返回码。统计时要明确是哪一层在报告结果，否则会把连接失败算成业务失败，或反过来把业务失败漏掉。