Keepalived 不支持 vrrp_notify_priority 配置项，其通知机制仅基于 VRRP 状态变更（MASTER/BACKUP/FAULT），由 notify_master、notify_backup、notify_fault 或通用 notify 指令触发，优先级变化本身不引发通知。
Keepalived 并没有 vrrp_notify_priority 这个配置项——它不属于官方支持的参数，也不出现在任何版本（包括最新稳定版 2.2.x 及 2.4.x）的文档或源码中。实际生效的通知机制依赖的是标准的 notify、notify_master、notify_backup 和 notify_fault 指令，配合脚本逻辑实现状态感知。
为什么不存在 vrrp_notify_priority
Keepalived 的通知触发完全基于 VRRP 状态机跳转（INIT→MASTER/BACKUP/FAULT），而非优先级数值变化本身。优先级（priority）仅参与选举决策，不直接触发通知；即使优先级因 track_interface 或 vrrp_script 动态下调，只要状态未变（比如仍为 BACKUP），就不会调用 notify 脚本。因此，所谓“监听优先级变化来发通知”属于常见误解。
真正可控的通知触发点
Keepalived 明确支持以下四类状态变更通知：
- notify_master：当前节点晋升为 MASTER 后立即执行
- notify_backup：当前节点降级为 BACKUP 后立即执行
- notify_fault：进入 FAULT 状态（如健康检查连续失败、配置异常）时执行
-
notify：通用入口，脚本内通过位置参数
$1判断状态（master/backup/fault），推荐统一使用
如何在脚本中安全反映优先级意图
若需让通知内容体现“为何切换”，可在 notify 脚本中主动读取当前运行时优先级，增强可追溯性：
- 使用
keepalived -D -f /etc/keepalived/keepalived.conf启动时加-D可查看日志中的 priority 实时值 - 在 notify.sh 中通过
pidof keepalived | xargs -I{} cat /proc/{}/status 2>/dev/null | grep -i priority获取（不推荐，不稳定） - 更可靠方式：将关键权重逻辑显式写入脚本，例如检测到
eth0故障时，在track_interface对应的脚本里提前记录日志或写标记文件，再由 notify 脚本读取并写入邮件正文
避免踩坑的关键实践
不要尝试用非标参数伪造“优先级通知”。应聚焦于：
- 确保
notify脚本有执行权限（chmod +x）且路径在keepalived.conf中正确引用 - 脚本开头加
#!/bin/bash，避免因解释器缺失导致静默失败 - 所有外部命令（如
mail、sendemail）需预装并测试通路，建议加超时和错误重试 - 禁用抢占模式（
nopreempt）时，MASTER 恢复后不会自动抢回，此时notify_master不会再次触发——这是预期行为，不是 bug
