主备切换脚本执行失败常因权限不足导致静默失败；需检查脚本执行权限、调用用户与文件所有权匹配、内部命令路径及环境变量、SELinux/noexec等限制。
主备切换过程中脚本执行失败，常被归因为“服务异常”或“配置错误”，但实际有相当一部分案例是权限不足导致的静默失败——脚本根本没跑起来，日志里连启动记录都没有。这类问题在高可用架构（如Keepalived+脚本、Pacemaker、自研VIP切换逻辑）中尤为典型。
确认脚本是否具备执行权限
主备切换通常由root或特定服务用户触发，但脚本本身可能由非root用户创建，且未设执行位。
- 检查脚本权限：运行 ls -l /path/to/switch.sh，确认输出中所有者位置有 x（如 -rwxr-xr--），若为 -rw-r--r-- 则缺少执行权
- 补全执行权限：用 sudo chmod u+x /path/to/switch.sh 赋予所有者执行权（不建议直接 chmod 777）
- 特别注意：如果脚本通过软链接调用，需检查链接目标文件本身的权限，而非链接文件
验证执行用户与脚本所有权匹配
主备切换脚本往往由keepalived、corosync或systemd以特定用户身份调用（常见为root），但脚本若属普通用户且无组/其他执行权限，就会失败。
- 运行 ls -l /path/to/switch.sh 查看第三列（所有者）和第四列（所属组）
- 确认调用用户能否执行它：例如脚本属 deploy:app，而keepalived以 root 运行，则依赖root对文件的other权限；若属主不是root且other无x，就会Permission denied
- 稳妥做法：用 sudo chown root:root /path/to/switch.sh 并设权限为 755，确保root可执行、组和其他可读可执行
检查脚本内调用的命令与路径权限
脚本能执行，不代表它内部的操作能成功。常见陷阱是脚本里用了相对路径、硬编码用户家目录（如~/bin/do_failover）、或调用了无执行权的二进制工具。
- 在脚本开头添加 set -x 并重定向日志，观察哪一行卡住或报错
- 将脚本中所有路径改为绝对路径，尤其避免 ~、.、.. 等易受工作目录影响的写法
- 检查脚本依赖的命令（如 ip、mysql、curl）是否在PATH中，且对应二进制文件自身有执行权限（ls -l $(which ip)）
排查环境变量与SELinux/安全模块限制
主备切换脚本多在最小化环境（如systemd-run、cron、keepalived exec）中运行，PATH极短，且可能受SELinux、AppArmor等强制访问控制拦截。
- 在脚本第一行加入 env > /tmp/switch_env.log 2>&1，对比手动执行时的环境差异
- 临时关闭SELinux测试：sudo setenforce 0，若此时切换成功，说明策略限制了脚本或其子进程（需后续用 ausearch -m avc -ts recent 定位具体拒绝项）
- 检查脚本所在目录是否挂载了 noexec 选项：mount | grep $(dirname /path/to/switch.sh)，若含 noexec，需换到允许执行的分区
