Linux 软件版本回滚与管理

回滚需协同二进制、配置、依赖与运行时状态：apt 降级须查版本并锁定；dnf/yum 应优先用 history undo；/usr/local/bin 替换需原子操作并检查占用；配置文件必须版本化管理。

回滚 apt 安装的软件包时，apt install 加旧版本号不总管用

直接 apt install package=1.2.3-4ubuntu1 看似合理，但常失败——因为目标版本可能已被 apt update 清出本地索引，或依赖关系已不满足当前系统状态。

真正可靠的做法是先查可用历史版本，再锁定并降级：

• 用 apt list --all-versions package-name 确认旧版本是否还在缓存里（注意：只显示当前源里还存在的版本）
• 若不在列表中，得从 /var/cache/apt/archives/ 手动找 .deb 文件，或去对应发行版的归档源（如 Ubuntu Archive）下载匹配的 .deb
• 安装前务必用 dpkg -I xxx.deb 检查 Depends: 字段，避免强行安装引发依赖断裂
• 成功安装后立即运行 apt-mark hold package-name，否则下次 apt upgrade 会把它又刷回去

rpm 系统里 yum downgrade 报 No package found

yum downgrade 本质是查找“比当前低的、且在启用源中可用”的版本，不是万能回滚命令。它不读取本地 RPM 缓存，也不访问历史事务记录。

更稳的路径是结合 dnf history（RHEL 8+/centos 8+）或 yum history（旧版）：

• 先运行 dnf history list package-name 找到上次升级前的 transaction ID
• 执行 dnf history undo N（N 是 ID），这会自动计算反向操作，包括依赖还原
• 若事务已过期被清理，就得手动 rpm -Uvh --oldpackage xxx.rpm，注意加 --oldpackage 参数，否则 rpm 拒绝降级
• 别用 rpm -ivh 强装——它不处理冲突文件，极易导致 /usr/bin 下二进制被覆盖却没删旧符号链接

没有包管理器权限时，如何安全替换 /usr/local/bin 下的二进制

很多自编译或 curl | bash 装的工具（比如 terraform、jq）就扔这儿，回滚全靠手动换文件。风险在于：进程可能正占用旧文件，直接 mv 会触发 Text file busy 错误。

• 先用 lsof +D /usr/local/bin 检查是否有进程锁着目标文件
• 停掉相关服务或终端会话（尤其 tmux/screen 里后台跑的），不要只 kill 进程名——子进程可能继承了 fd
• 用原子替换：install -m 0755 new-binary /usr/local/bin/binary，比 cp 更安全（install 自动处理 setuid/setgid 位）
• 如果旧版二进制是静态链接但新版是动态的，记得用 ldd new-binary 核对 libc 版本兼容性，老系统上跑新二进制可能直接 Segmentation fault

systemctl restart 后服务起不来，可能是配置文件版本不匹配

回滚软件本身不等于回滚配置。新版软件常引入配置项废弃或语义变更（比如 nginx 的 ssl_protocols 从 TLSv1.2+ 变成默认禁用 TLSv1.0），旧配置在新二进制下可能语法报错，反之亦然。

• 启动失败时立刻看 journalctl -u service-name --since "1 minute ago"，重点扫 Failed to parse、unknown directive 类错误
• 配置文件通常没版本号，得靠 git log -p /etc/service-name/conf.d/ 或 etckeeper 记录来回溯
• 临时救急可加 --no-pager 和 -t 参数验证：nginx -t -c /etc/nginx/nginx.conf，别跳过这步直接 restart
• 生产环境建议把 /etc 目录纳入版本控制（哪怕只是每天 rsync 到另一台机器），配置漂移比二进制漂移更难排查

回滚从来不是单点操作，二进制、配置、依赖、运行时状态，四者只要一个没对齐，服务就卡在启动半途。最麻烦的是那种“看似启动成功，但某条 API 路径静默返回 500”的情况——它不会报错，只会等你半夜被告警叫醒。