Rocky和Alma哪些更新需要重启？

Rocky Linux 和 AlmaLinux 中哪些更新需要重启

在 Rocky Linux 和 AlmaLinux 中，dnf update 会将新文件写入磁盘，然后停止。当前启动的内核会继续运行。已经打开某个库文件的进程会继续使用已打开的副本，因为 Linux 会在磁盘上保留旧文件，直到持有该文件的最后一个进程退出。因此，即使系统报告没有可用更新，仍可能运行着已被这些更新替换的代码。这两种发行版在这方面没有区别，因为它们都重新构建相同的 Red Hat 源代码；选择 Rocky 还是 Alma 取决于兼容性承诺和 CPU 支持，而不是本文介绍的内容。下面的命令也与 CentOS 主机使用的命令相同，这并非巧合：这两个项目都是在 2020 年 Stream 公告后作为 CentOS 替代品创建的。

哪些更新需要重启，哪些只需要重启服务，必须由系统本身判断。用于获取答案的命令是 needs-restarting。更新分为 3 个级别。内核和少量核心软件包需要完整重启。普通库更新需要重启使用这些库的服务。其他更新在 RPM 完成后立即生效。

安装 needs-restarting

needs-restarting 是一个 DNF 插件。该插件包含在 dnf-plugins-core 中，而大多数 Rocky 和 Alma 安装通常已经包含此软件包。/usr/bin/needs-restarting 命令是 dnf-utils 提供的一个简单包装器。

sudo dnf install -y dnf-utils
needs-restarting --help

两种写法运行的是相同的代码，因为该包装器会调用 DNF 子命令：

needs-restarting -r
dnf needs-restarting -r

这两个软件包都来自发行版自己的软件仓库，因此无需为此启用 EPEL 或 CRB 软件仓库。

在 Rocky Linux 10 和 AlmaLinux 10 系列中，dnf 是 DNF 5，needs-restarting 是其自身的命令，由 dnf5-plugins 软件包提供。在这些系统中，不带选项运行 dnf needs-restarting 会直接给出是否需要重启的结果。仍然接受 -r，但手册说明它不起作用，仅用于让 DNF 4 脚本继续运行。

第 1 层：需要重启的更新

先运行重启检查。它只读取 RPM 数据库和系统启动时间，不执行其他操作，因此速度很快，也不需要 root。

needs-restarting -r

如果启动后没有发生任何重要更改，它会输出两行：

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

如果检测到更改，它会先输出 Core libraries or services have been updated since boot-up:，然后输出找到的软件包名称，最后输出：

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

退出代码表示相同的结果：不需要重启时为 0，需要重启时为 1。脚本应根据这个退出代码处理。

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

这里的退出代码 1 是正常结果，不表示失败。在 set -e 下，未加保护的 needs-restarting -r 会在这一行结束脚本，因此上面的示例将其放在 if 中。

触发重启判断的软件包来自插件内部的一份简短硬编码列表。当前版本包含 kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon 和 microcode_ctl。较旧的插件构建版本列表略短，因此应检查实际版本，不要直接假定。

列表中的每个条目都有明确原因。新的 kernel 软件包只会将文件写入 /boot 和 /lib/modules，而运行中的内核无法在自身运行期间被替换，因此必须启动新内核后才会生效。系统中的每个进程都会链接 glibc，这意味着“重启受影响的服务”也包括重启 PID 1；重启系统是更安全的做法。dbus 和 dbus-broker 承载系统上的所有客户端连接，因此在运行中的机器上停止总线会中断正在使用它的客户端。linux-firmware 和 microcode_ctl 会在启动时加载；对于 VPS，微码部分通常不会产生可观察的变化，因为物理 CPU 由虚拟机管理程序所在的主机控制。

您可以添加自己的软件包。/etc/dnf/plugins/needs-restarting.d/ 下的任何 .conf 文件都会被读取为软件包名称列表，每行一个名称；这些名称会加入重启列表。

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

这是策略选择，不是修复措施。它表示：“TLS 库发生变化时，我更愿意重启，而不是逐一找出所有已加载该库的服务。”

重启提示实际依据的内容

needs-restarting -r 不会将当前运行的内核版本与最新安装的内核版本进行比较，而是比较时间戳。对于核心软件包列表中的每个软件包，它都会读取 RPM 安装时间，并将其与系统启动时间进行比较。如果某个核心软件包的安装时间晚于上次启动时间，结果就是“需要重启”。如果可以使用 systemd 的 D-Bus，启动时间来自 UnitsLoadStartTimestamp；否则，取 /proc/1 的修改时间和 /proc/stat 中的 btime 字段两者中较晚的时间。

这一机制有一个需要注意的后果。如果安装内核后重启，但由于启动默认项被固定，系统又进入了旧内核，那么安装时间现在早于启动时间，needs-restarting -r 就不会再提示。它正确回答了自己的问题，但不是您要问的问题。请单独检查内核。

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

第一个命令显示当前运行的内核。rpm -q --last kernel 的第一行是最近安装的内核。grubby --default-kernel 显示 bootloader 下次将选择的内核。如果这三项不一致，请先修复启动默认项，再重启无法通过控制台访问的机器。

第 2 层：需要重启服务的更新

当 RPM 替换共享库时，它会解除旧文件的链接并写入新文件。已经映射旧文件的进程会继续保留旧 inode，并继续执行旧代码。openssl-libs 是最需要关注的情况：libcrypto 中的修复只有在 Web 服务器重启后才会生效。

sudo needs-restarting -s

此命令列出自身文件或依赖项文件在服务启动后发生更新的 systemd 服务。使用 sudo。如果不使用 root，该工具只能读取属于您自己进程的 /proc 条目，因此会静默漏报，导致列表看起来比实际情况更好。

sudo needs-restarting
sudo needs-restarting --exclude-services

第一条命令输出每个受影响进程的 PID 和命令行。第二条命令排除已由 systemd 服务覆盖的进程，剩下登录 shell、tmux 会话、cron 任务以及您手动启动的进程。这些进程不会自动重启。

如果列表中的服务同时属于需要重启系统的软件包，工具会在其上方输出 Warning: The following services should not be restarted but require a reboot:。请按字面理解这条提示，直接重启系统。

其余服务逐个重启。每重启一个，都先确认其状态，再处理下一个。

sudo systemctl restart nginx
systemctl status nginx

不要将列表通过管道传给 systemctl restart。原因是您自己的 SSH 会话。在 RHEL 系列系统中，sshd.service 随 KillMode=process 一起提供，因此重启它时会向监听 daemon 发送信号，而不会终止每个连接对应的进程，打开的会话也能继续保持。使用 systemctl cat sshd | grep KillMode 在您自己的服务器上确认这一点；无论如何，第一次操作时都应保留第二个会话。

不使用 DNF 也可以找到相同的进程。当您需要查看涉及的文件路径时，这种方式很有用：

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL 表示已从磁盘删除但仍被映射的文件。执行操作前先读取路径。已删除的临时文件和基于内存的文件也会出现在这里，但它们并不是重启任何服务的理由。

第 3 级：其他所有情况

大多数更新都属于这一类，不需要额外处理。某个软件包的文件只有在命令启动时才会读取，例如 curl、tar、vim 或 dnf 本身。RPM 完成后，这类更新就已完全生效，因为下一次运行时会读取新的二进制文件。配置文件、脚本、文档和数据包也一样。needs-restarting 不会提及其中任何一项。这种没有输出是正确结果，不是检测遗漏。

这一类唯一需要注意的是进程持续时间。更新前启动的进程会继续使用旧的可执行文件，直到进程退出，即使该软件包非常简单。这正是 sudo needs-restarting --exclude-services 的用途。

为什么使用 dnf-automatic 的机器可能数周都没有应用修复

这正是三层机制不再只是细节的地方。使用 dnf-automatic 自动更新会按计划安装软件包，而 /etc/dnf/automatic.conf 中的默认 reboot 设置为 never。启用 apply_updates = yes 和 reboot = never 后，机器可以在 6 周内安装 6 个内核更新和一个 glibc 修复，但仍在运行第 0 周启动时使用的内核和 C 库。更新日志看起来完全正常，但运行中的系统实际上没有应用这些更新。

修复方法是在 /etc/dnf/automatic.conf 中加入以下 3 行：

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot 接受 never、when-changed 和 when-needed。never 是默认值，所有决定都由您自行处理。when-changed 会在任何修改软件包的事务完成后重启，方式简单直接，但行为可预测。when-needed 会询问 DNF 刚刚应用的事务是否需要重启，因此仅更新用户空间的软件包时不会重启。reboot_command 是实际执行的命令，默认会提前 5 分钟向已登录用户发出警告。设置 random_sleep 和计时器的计划，使重启发生在您能够监控机器恢复的维护窗口内。

使用 systemctl list-timers 'dnf-*' 检查您启用的是哪个单元。dnf-automatic 随附多个变体，它们的行为并不完全相同，因此仅查看配置文件无法确定实际运行的内容。

计划任务运行后，不要只看日志，应直接向机器确认：

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

如果无法安排重启，在 VPS 上实时修补内核是另一种方案。它可以在不重启的情况下，将某些内核修复应用到正在运行的内核。它只能覆盖一部分内核问题，也不会处理 glibc 或您的服务，因此应将其视为延长重启间隔的方法，而不是完全停止重启。需要重启时，应有计划地执行，并保持登录状态，直到机器响应，因为内核更新是机器无法恢复运行的最常见原因。对于没有控制台访问权限的主机，重启前请阅读VPS 在内核更新后无法启动时的处理方法，并将重启检查纳入定期服务器维护清单，避免只在发生故障后才想起这项检查。

Ubuntu 和 Debian 上的相同任务

混合部署环境需要使用对应的命令。在 Ubuntu 和 Debian 上，重启标志是一个文件，而不是命令：软件包脚本会创建 /run/reboot-required，/run/reboot-required.pkgs 会列出请求创建该标志的所有软件包，因此 [ -f /run/reboot-required ] 是 needs-restarting -r 的直接等价形式。较早的文档会写作 /var/run/reboot-required，它指向同一个文件，因为 /var/run 是指向 /run 的符号链接。服务端对应的是 needrestart。该服务默认安装在较新的 Ubuntu Server 版本中，会在 apt upgrade 期间运行；也可以单独使用 sudo needrestart -r l，列出需要重启的内容，而不执行任何操作。这里同样存在自动更新缺口，解决方法也相同：Ubuntu 上的 unattended-upgrades 会在 /etc/apt/apt.conf.d/50unattended-upgrades 中处理 Unattended-Upgrade::Automatic-Reboot "true"; 和 Unattended-Upgrade::Automatic-Reboot-Time "02:00";。

故障模式及其表现

• needs-restarting: command not found 表示未安装 dnf-utils。请安装它，或改用 dnf needs-restarting；只要存在 dnf-plugins-core，它就可以工作。
• 脚本在重启检查处停止且不显示错误消息，表示 set -e 返回了退出码 1。该代码表示“需要重启”。请根据该退出码进行分支处理，不要让它直接终止脚本。
• 库更新后，needs-restarting -s 通常不输出任何内容，表示运行时未使用 sudo。没有 root 权限时，它只能看到您自己的进程。
• needs-restarting -r 报告无需重启，而 uname -r 显示旧版本，表示系统启动时使用的是较旧的内核。该检查会比较安装时间和启动时间，而这两个时间点都早于当前时间。请查看 grubby --default-kernel。
• 某个服务在您重启几分钟后又出现在下一次运行中，通常表示它被其他组件重新启动，或者该单元未能恢复运行。再次重启前，请先读取该单元的 systemctl status。

FAQ

dnf update 会在 Rocky Linux 上重启服务吗？

通常不会。事务会写入文件，然后结束。某些软件包包含 RPM scriptlet，升级时会重启其自身服务。因此，行为取决于具体软件包，不能视为系统级保证。以 sudo needs-restarting -s 为准：它会列出服务启动后自身文件或依赖项文件发生变化的服务，不论 scriptlet 执行了什么操作。

为什么安装了更新的内核后，needs-restarting -r 仍显示无需重启？

因为它会将少量核心软件包的 RPM 安装时间与系统启动时间进行比较。它不会比较正在运行的内核版本与已安装的最新内核版本。如果安装内核后重启，但由于 bootloader 默认指向旧内核，系统又使用了旧内核启动，那么安装时间早于启动时间，该检查就不会报告需要重启。运行 uname -r、rpm -q --last kernel 和 sudo grubby --default-kernel 查看实际情况。

Rocky 和 Alma 上哪些软件包会触发重启提示？

插件内部有一个硬编码列表。当前版本包含 kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon 和 microcode_ctl。您可以扩展该列表：将包含软件包名称的 .conf 文件放入 /etc/dnf/plugins/needs-restarting.d/，每行写一个名称。这些名称也会计入重启判断结果。

dnf-automatic 能自行重启服务器吗？

可以。在 /etc/dnf/automatic.conf 的 [commands] 部分设置 reboot = when-needed 后，只有它执行的事务要求重启时，系统才会重启。when-changed 会在任何软件包发生更改后重启，never 是默认设置。reboot_command 控制重启方式，其默认值会向已登录用户提前五分钟发出警告。仅应在能够恢复启动的机器上启用此功能，因为无法访问控制台的 VPS 发生无人值守重启后，可能无法恢复。

needs-restarting 能检测容器内的进程吗？

不能有效检测。它会将运行中的进程与主机 RPM 数据库进行匹配，而容器镜像中的软件包不在该数据库中。因此，镜像中内置的过期库不会显示出来。请重新构建镜像并重新部署。主机侧仍然重要：容器运行时和容器共享的内核都属于主机软件包，这些内容会被检测到。