从一次RPM打包失败说起：深入理解Spec文件中%pre、%post脚本的正确使用姿势
在Linux软件分发领域，RPM包管理系统以其严谨的依赖管理和事务完整性著称。但这份严谨也带来了特殊的开发约束——当我们在spec文件中编写%pre、%post等脚本时，稍有不慎就会触发事务锁冲突。最近在为内部GIS服务构建RPM包时，我就因为脚本中一个看似合理的卸载操作，陷入了经典的.rpm.lock死局。
这种问题往往发生在需要执行复杂安装逻辑的场景：数据迁移、服务重启、依赖版本检查...作为软件工程师，我们本能地希望在安装流程中插入这些操作，却忽略了RPM事务的原子性要求。本文将结合事务锁机制，拆解各脚本阶段的执行上下文，并给出可落地的解决方案。
1. RPM脚本阶段的执行上下文剖析
1.1 事务锁与脚本执行的关系
当RPM开始安装操作时，会先在/var/lib/rpm/.rpm.lock建立独占锁。这个锁保护的是整个RPM数据库的完整性，确保不会出现并发修改。理解这一点至关重要——任何在脚本中触发新RPM事务的操作（安装/卸载/升级）都会导致锁冲突。
典型的冲突场景包括：
- 在%pre脚本中卸载旧版本（
rpm -e） - 在%post脚本中安装依赖包（
yum install） - 在%pretrans中检查并升级组件
这些操作看似合理，实则违反了RPM的事务隔离原则。就像在数据库事务中执行DDL操作，必然引发锁等待超时。
1.2 各脚本阶段的执行时机
| 脚本阶段 | 触发时机 | 事务锁状态 | 典型误用场景 |
|---|---|---|---|
| %pretrans | 事务开始前 | 未加锁 | 过早执行文件操作 |
| %pre | 文件解压前 | 已加锁 | 尝试修改RPM数据库 |
| %post | 文件解压后 | 已加锁 | 安装额外软件包 |
| %preun | 卸载开始前 | 已加锁 | 备份时误删文件 |
| %postun | 卸载完成后 | 已加锁 | 残留服务未清理 |
| %posttrans | 所有事务完成后 | 已释放 | 未处理跨版本升级逻辑 |
这个表格揭示了关键规律：除了%pretrans和%posttrans，其他阶段都在事务锁保护下执行。这就是为什么在%pre中卸载软件会失败——它试图在已有事务中开启新事务。
2. 安全编写安装脚本的实践方案
2.1 替代方案：使用Triggers机制
当需要在安装过程中与其他包交互时，Triggers是更安全的选择。它们由RPM引擎在适当时机自动调度，不会破坏事务完整性。例如处理旧版本升级：
# 定义触发器检查旧版本 %triggerun -- GeoSceneInnovatorServer < 4.0.1 # 旧版本卸载前执行备份 mkdir -p /opt/GeoSceneInnovatorServer/oldVersion cp -a /opt/GeoSceneInnovatorServer/data /opt/GeoSceneInnovatorServer/oldVersion/这种方式的优势在于：
- 由RPM引擎控制执行时机
- 不会造成递归事务
- 明确声明了版本范围
2.2 依赖声明优于运行时检查
与其在%pre脚本中用rpm -q检查依赖，不如在spec头部显式声明：
Requires: libgeos >= 3.8 Conflicts: old-package <= 2.4这能让包管理器在事务开始前就解决所有依赖关系，避免在锁定阶段进行动态检查。
3. 复杂场景的架构设计模式
3.1 多阶段部署方案
对于需要安装后配置的服务，推荐采用两阶段打包：
- 主包（Core）：包含基础文件和%posttrans脚本
- 配置包（Config）：包含初始化逻辑
# 主包spec片段 %posttrans # 安全执行初始化 if [ -f /etc/service-firstboot ]; then /usr/libexec/service-init.sh rm -f /etc/service-firstboot fi # 配置包spec片段 %install touch %{buildroot}/etc/service-firstboot这种解耦设计让配置操作在事务外执行，完全避免锁冲突。
3.2 服务启停的最佳实践
许多服务需要在升级时重启，但直接写在%post会导致问题。正确的做法是：
%post # 仅注册服务，不立即启动 systemctl preset %{name}.service >/dev/null 2>&1 || : %preun # 优雅停止服务 if [ $1 -eq 0 ]; then systemctl --no-reload disable --now %{name}.service >/dev/null 2>&1 || : fi配合systemd的Restart=on-failure策略，可以确保服务状态一致性。
4. 调试与问题诊断技巧
4.1 事务锁冲突的应急处理
当遇到.rpm.lock锁定时，可以按以下流程诊断：
- 检查是否有残留进程：
lsof /var/lib/rpm/.rpm.lock - 查看当前事务：
ps aux | grep rpm - 安全清除锁文件（仅在确认无事务运行时）：
rm -f /var/lib/rpm/__db*
警告：直接删除锁文件可能导致数据库损坏，应作为最后手段
4.2 脚本调试输出技巧
在脚本中添加调试信息时，建议重定向到持久化日志：
%post { echo "执行时间: $(date)" echo "环境变量:" env echo "文件列表:" ls -l /opt/service/ } >> /var/log/service-install.log 2>&1避免直接使用echo到stdout，这可能干扰RPM的输出解析。
在经历多次打包失败后，我发现最可靠的原则是：让安装脚本保持最小化。所有非必要的操作都应该通过外部工具或守护进程完成。比如用cron调度首次运行配置，而不是在%post中直接执行。这种架构不仅能避免事务问题，还使包更易于维护和调试。
