RPM Spec中%post钩子执行时配置文件未重命名导致重启异常问题

这确实是RPM包构建中很容易碰到的时序陷阱——%post钩子的执行时机早于%config(noreplace)的配置文件重命名操作，所以当你在%post里执行服务重启逻辑时，系统还没完成旧配置文件的.rpmsave重命名，自然会导致依赖配置状态的操作出现异常。

下面是几个靠谱的解决方案，按推荐优先级排序：

1. 改用%posttrans钩子（最优解） #

RPM的%posttrans是在整个包安装/更新流程完全结束后才触发的，包括所有文件拷贝、配置文件重命名（就是你依赖的%config(noreplace)逻辑）都已经完成。把你的服务重启逻辑移到这里，就能确保拿到最终的配置文件状态。

示例Spec代码片段：

%posttrans
# 判断是首次安装还是更新操作
if [ $1 -eq 1 ]; then
    # 首次安装：启动服务
    systemctl start your-daemon.service
else
    # 更新操作：检查是否有配置文件被重命名
    if [ -f /etc/your-daemon.conf.rpmsave ]; then
        # 存在rpmsave文件，说明原配置被保留，按需重启服务
        systemctl restart your-daemon.service
    fi
fi

2. 在%post中主动校验配置文件状态（兼容方案） #

如果因为某些原因必须在%post里执行逻辑，可以通过主动检查.rpmsave/.rpmnew文件的存在性，或者对比配置文件内容，来判断是否需要执行重启。不建议用sleep这类依赖系统速度的方式，可靠性太差。

示例代码：

%post
# 检查是否生成了rpmsave文件
if [ -f /etc/your-daemon.conf.rpmsave ]; then
    systemctl restart your-daemon.service
elif [ -f /etc/your-daemon.conf.rpmnew ]; then
    # 对比rpmnew和当前配置文件内容，如果不同则重启
    if ! cmp -s /etc/your-daemon.conf /etc/your-daemon.conf.rpmnew; then
        systemctl restart your-daemon.service
    fi
fi

3. 验证时序问题（调试用） #

如果想彻底确认各个阶段的文件状态，可以在Spec中添加日志输出，追踪每个钩子阶段的配置文件变化：

%pre
echo "[PRE] 配置文件状态:" >> /tmp/rpm_daemon_debug.log
ls -l /etc/your-daemon.conf* >> /tmp/rpm_daemon_debug.log

%post
echo "[POST] 配置文件状态:" >> /tmp/rpm_daemon_debug.log
ls -l /etc/your-daemon.conf* >> /tmp/rpm_daemon_debug.log

%posttrans
echo "[POSTTRANS] 配置文件状态:" >> /tmp/rpm_daemon_debug.log
ls -l /etc/your-daemon.conf* >> /tmp/rpm_daemon_debug.log

执行更新后查看/tmp/rpm_daemon_debug.log，就能清晰看到%post阶段确实还没生成.rpmsave文件，而%posttrans阶段已经完成重命名了。

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