Linux 运维脚本异常退出的防护手段

应启用 set -e、set -u、set -o pipefail 严格检查错误与变量，用 trap 注册清理函数覆盖 EXIT/int/TERM，开头校验命令依赖与版本，统一日志格式和退出码，敏感信息脱敏，竞态需原子锁。

脚本未设 set -e 导致错误被忽略

很多运维脚本执行到某条命令失败（比如 cp 权限不足、curl 超时、systemctl start 服务启动失败），但后续命令仍继续执行，最终状态不可控。根本原因常是没启用严格错误检查。

建议在脚本开头立即加入：

set -e

，它会让 shell 在任意命令返回非零退出码时立即终止脚本。

• 搭配 set -u 可捕获未定义变量引用（如误写 $USER_NAME 实际应为 $USERNAME）
• 搭配 set -o pipefail 确保管道中任一环节失败都触发退出（否则 cmd1 | cmd2 中仅 cmd2 的退出码被检查）
• 若某条命令允许失败，用 cmd || true 或 set +e; cmd; set -e 临时关闭

关键步骤缺少 trap 清理导致残留状态

脚本中途异常退出（比如被 kill -9、磁盘满、Ctrl+C），临时文件、锁文件、挂载点、网络命名空间等可能滞留，下次运行直接失败。

必须用 trap 注册清理逻辑，覆盖 EXIT、INT、TERM 信号：

cleanup() {   rm -f /tmp/my_script.lock   umount /mnt/tempfs 2>/dev/null   ip netns delete ns_test 2>/dev/null } trap cleanup EXIT INT TERM

• trap 必须在资源创建前注册，否则可能漏挂
• 避免在 cleanup 中调用可能再次失败的复杂逻辑（如远程 API 请求），专注本地确定性操作
• 注意 kill -9 无法被捕获，所以关键锁文件建议配合超时和外部检测机制

依赖命令缺失或版本不兼容引发静默失败

脚本在新机器上跑崩，报错却是“command not found”或“invalid option”，但错误信息被重定向或没进日志——实际是 rsync --delete-delay 在旧版 rsync 中不存在，或 jq -r '.id' 在无 jq 环境下直接退出 127。

应在脚本开头做最小依赖校验：

for cmd in curl jq systemctl rsync; do   if ! command -v "$cmd" >/dev/null; then     echo "ERROR: required command '$cmd' not found" >&2     exit 1   fi done

• 对关键选项做运行时探测，例如 rsync --version | grep -q '3.1' || { echo "rsync 3.1+ required"; exit 1; }
• 避免用 which，改用 command -v（POSIX 兼容且不依赖 PATH 搜索顺序）
• 不要假设 /bin/bash 存在，用 #!/usr/bin/env bash 更健壮

日志与退出码未标准化导致排障困难

运维脚本出问题后，只能靠 echo 输出猜上下文，或者发现脚本返回了 0 却什么都没干——这是因为没统一控制日志格式和最终退出码。

推荐固定模式：所有输出走 logger 或带时间戳的 echo，且主逻辑用子 shell 封装，显式返回退出码：

main() {   # ... 业务逻辑   return $? } main "$@" 2>&1 | logger -t "my-backup-script" exit ${PIPESTATUS[0]}

• 用 ${PIPESTATUS[@]} 捕获管道各段真实退出码，而非只看最后一条
• 避免在函数里直接 exit，优先 return，让顶层统一处理
• 敏感信息（密码、Token）绝不能进日志，哪怕调试阶段也要过滤

真正难防的是多进程协作场景下的竞态——比如两个实例同时检查锁文件、同时判定“没人用”，然后双双写入。这种得靠原子操作（ln -s 创建锁、flock 文件描述符锁）或外部协调服务，不是单个脚本能兜底的。