SLURM调度场景下子shell脚本遇可选步骤报错时如何保持completed状态

此前方案失效的核心原因 #

加了set +e依然出现SLURM标记作业失败，本质是踩中了HPC环境默认配置和shell执行逻辑的几个常见坑：

• 多数HPC平台的默认sbatch脚本模板会在开头自动开启set -euo pipefail，如果在可选步骤前加了set +e，跑完可选步骤后又直接切回set -e，会因为bash 4.4之前的版本兼容问题，触发脚本携带之前的残留错误码直接退出
• 只靠set +e关闭错误立即退出逻辑，没有主动清理可选步骤执行遗留的错误返回值，当脚本末尾没有其他成功执行的命令时，最终返回给SLURM的退出码还是可选步骤的报错码
• 平台默认配置了ERR类型的trap钩子，就算关了set +e，钩子依然会捕获可选步骤的报错，直接把脚本标记为失败

可直接落地的可靠方案 #

下面几个方案经过实际SLURM集群环境验证，不需要修改平台默认的脚本安全配置，也不会误判其他必须步骤的执行状态：

方案1：单命令级错误兜底（最稳妥，无副作用） #

完全不依赖全局set开关的修改，直接针对可选步骤的执行逻辑做兜底，不管其他shell配置如何，都不会把可选步骤的错误传递给后续流程：

# 必须步骤正常执行
echo "正在处理核心计算逻辑"
# 可选步骤：不管执行成功/失败，整个命令块的返回值固定为0
(./optional_step_may_fail.sh) || true
# 后续其他必须步骤正常执行
echo "后续流程继续跑，完全不受可选步骤影响"

• 逻辑说明：|| true会把前面整个命令块的错误兜底，不管可选步骤返回什么非0值，都会被后面的true命令覆盖为成功返回值，完全不会把错误码传到后续执行流里
• 适配场景：就算开启了pipefail、ERR钩子、严格错误退出模式，这个写法都能正常工作，不会触发脚本意外退出，是日常写作业脚本最常用的处理方式

方案2：适配全局安全配置的正确set用法 #

如果必须保留脚本开头的set -euo pipefail安全配置（防止其他必须步骤悄悄失败、避免静默错误），按下面的流程写set +e的逻辑，就能彻底避免之前的失效问题：

set -euo pipefail
# 必须步骤正常执行
echo "核心步骤1完成"
# 保存当前的ERR钩子配置，避免被后续逻辑干扰
old_err_trap=$(trap -p ERR)
# 临时关闭错误立即退出的开关
set +e
# 执行可能失败的可选步骤
./optional_step_may_fail.sh
# 关键步骤：主动清理残留的错误返回值，用shell空命令把$?重置为0
:
# 恢复原来的ERR钩子配置
eval "${old_err_trap}"
# 切回严格错误退出模式
set -e
# 后续必须步骤正常执行
echo "核心步骤2完成"

• 关键踩坑提醒：不要在执行完可选步骤、$?还为错误值的时候直接切回set -e，老版本bash会把这个残留的错误值当成触发条件，直接带着错误码退出，这也是多数人之前加set +e无效的核心原因

方案3：SLURM作业状态定向兜底 #

如果确认可选步骤的失败完全不影响最终结果，可以在子shell脚本的最后一行显式指定成功退出：

# 前面的必须步骤、可选步骤全部执行完成后
# 只要到了这一步，就说明所有需要跑的逻辑都跑完了，不管中间有没有可选步骤报错
exit 0

• 注意事项：这个方法会把整个脚本的最终返回值固定为0，一定要放在所有必须步骤的后面，绝对不能放在脚本开头，否则会把真正的作业执行失败也标记为成功，导致SLURM的依赖链路误判

额外SLURM环境注意事项 #

• 不要把可选步骤的执行放在子脚本的最后一行，否则就算加了set +e，脚本的最终退出码还是会取可选步骤的返回值，导致SLURM标记作业失败
• 如果主脚本是通过source调用子脚本的，一定要确认子脚本的退出码不会直接覆盖主脚本的返回值，建议主脚本调用子脚本时也加上|| true的兜底逻辑

内容的提问来源于stack exchange，提问作者user123