Rocky AlmaLinux 哪些更新需要重新開機？

Rocky Linux 和 AlmaLinux 的哪些更新需要重新開機

在 Rocky Linux 和 AlmaLinux 上，dnf update 會將新檔案寫入磁碟，然後停止處理。已啟動的 kernel 會繼續執行。已開啟某個函式庫的程序會持續使用開啟時取得的副本，因為 Linux 會讓舊檔案留在磁碟上，直到持有該檔案的最後一個程序結束。因此，機器可能顯示沒有可用更新，但實際上仍在執行已被這些更新取代的程式碼。Rocky Linux 與 AlmaLinux 都重新建置相同的 Red Hat 來源，因此兩個發行版在這方面沒有差異；選擇 Rocky 或 Alma 取決於相容性承諾與 CPU 支援，而不是取決於本節所述的內容。以下命令也與 CentOS 主機使用的命令相同，這並非巧合：兩個專案在 2020 年 Stream 公告後，都是作為 CentOS 替代方案建立的。

哪些更新需要重新開機，哪些只需要重新啟動服務，必須由機器本身判斷。用來取得答案的命令是 needs-restarting。更新可分為 3 個層級。kernel 與少數核心套件需要完整重新開機。一般函式庫更新需要重新啟動使用這些函式庫的服務。其他更新在 RPM 完成後便已套用。

安裝 needs-restarting

needs-restarting 是 DNF 外掛程式。此外掛程式包含在 dnf-plugins-core 中，大多數 Rocky 和 Alma 安裝環境都已預先提供。/usr/bin/needs-restarting 指令是包含在 yum-utils 中的小型包裝程式，也可使用 dnf-utils 這個名稱呼叫。

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

兩種寫法會執行相同的程式碼，因為此包裝程式會呼叫 DNF 子命令：

needs-restarting -r
dnf needs-restarting -r

這兩個套件都來自發行版自己的套件庫，因此不需要啟用 EPEL 或 CRB 套件庫。

Rocky Linux 10 和 AlmaLinux 10 系列仍使用 DNF 4。截至 2026-10-09，兩者的 BaseOS 套件庫都提供 dnf 4.20.0，以及 dnf-plugins-core 4.7.0 和 yum-utils，但沒有 dnf5 套件。因此，當中的 needs-restarting 使用的就是本頁說明的相同 dnf-plugins-core 外掛程式，以下內容不需變更即可套用。這也包括 -r；它會產生重新開機提示及其結束代碼，因此請保留在您的指令碼中。

第 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 中。

觸發需要重新開機結果的套件，是 plugin 內部一份簡短的硬式編碼清單。目前版本包含 kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon 與 microcode_ctl。較舊的 plugin 建置版本所含的清單略短，因此請檢查自己的版本，不要直接假設。

清單中的每個項目都有明確原因。新的 kernel 套件只會將檔案寫入 /boot 與 /lib/modules，而執行中的 kernel 無法在自身執行期間被替換，因此必須等到開機後才會生效。系統上的每個程序都會連結 glibc，因此「重新啟動受影響的服務」也代表要重新啟動 PID 1；重新開機是較安全的做法。dbus 與 dbus-broker 承載系統上的所有用戶端連線，因此在執行中的機器上停止該 bus，會中斷正在使用它的用戶端。linux-firmware 與 microcode_ctl 會在開機時載入；在 VPS 上，microcode 通常不會造成可觀察的變化，因為實體 CPU 由 hypervisor 主機管理。

您可以加入自訂套件。/etc/dnf/plugins/needs-restarting.d/ 下的任何 .conf 檔案都會被讀取為套件名稱清單，每行一個名稱，這些名稱會加入重新開機清單。

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

這是原則選擇，不是修正措施。它表示：「TLS library 變更時，我寧可重新開機，也不想逐一找出所有載入該 library 的服務。」

實際上，重開機提示是如何判定的

needs-restarting -r 不會比較目前執行中的 kernel 版本與最新安裝的 kernel。它比較的是時間戳記。對於核心套件清單中的每個套件，它會讀取 RPM 安裝時間，再與系統開機時間比較。如果某個核心套件的安裝時間晚於上次開機時間，結果就是「需要重開機」。如果可用，開機時間會透過 D-Bus 從 systemd 的 UnitsLoadStartTimestamp 取得；否則，會使用 /proc/1 的修改時間與 /proc/stat 中的 btime 欄位兩者之中較晚的時間。

這個機制有一個值得注意的結果。如果你安裝 kernel、重新開機，卻因為開機預設值被固定而回到較舊的 kernel，安裝時間現在就早於開機時間，needs-restarting -r 也會停止提示。它正確回答了自己被設計來回答的問題，但不是你提出的問題。請另外檢查 kernel。

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

第一個命令會顯示目前正在執行的 kernel。rpm -q --last kernel 的第一行是最近安裝的 kernel。grubby --default-kernel 會顯示 bootloader 下次會選取的 kernel。如果這三者不一致，請先修正開機預設值，再重新開機無法透過主控台連線的機器。

需要重新啟動服務的更新

當 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-*' 確認啟用的是哪個 unit。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 表示尚未安裝 yum-utils。請安裝它，或改用 dnf needs-restarting；只要存在 dnf-plugins-core，該方法就能運作。
• 指令碼在重新開機檢查處停止，且沒有顯示錯誤訊息，表示 set -e 傳回了 exit code 1。此代碼表示「需要重新開機」，因此應針對該代碼分支處理，不要讓它直接終止指令碼。
• 程式庫更新後，needs-restarting -s 通常沒有輸出，表示執行時未使用 sudo。沒有 root 權限時，它只能查看你自己的程序。
• needs-restarting -r 顯示不需要重新開機，但 uname -r 顯示舊版本，表示系統是以較舊的 kernel 開機。此檢查會比較安裝時間與開機時間，而這兩個時間點目前都已經早於更新。請查看 grubby --default-kernel。
• 服務重新啟動數分鐘後，在下一次執行時又再次出現，通常表示有其他元件正在重新啟動它，或該 unit 未能成功恢復。再次重新啟動前，請先查看該 unit 的 systemctl status。

FAQ

dnf update 會在 Rocky Linux 上重新啟動服務嗎？

通常不會。交易程序會寫入檔案，然後結束。部分套件在升級時會執行 RPM scriptlet，重新啟動自身的服務，因此行為取決於個別套件，並非系統層級的保證。請以 sudo needs-restarting -s 為準：它會列出服務啟動後，其檔案或相依套件的檔案曾變更的服務，不論 scriptlet 執行了什麼操作。

為什麼安裝較新的 kernel 後，needs-restarting -r 仍顯示不需要重新開機？

因為它會比較少數核心套件的 RPM 安裝時間與系統開機時間。它不會比較目前執行中的 kernel 版本與已安裝的最新版本。如果你安裝 kernel 後重新開機，但 bootloader 的預設設定讓系統使用較舊的 kernel，安裝時間就早於開機時間，因此檢查不會回報問題。請執行 uname -r、rpm -q --last kernel 和 sudo grubby --default-kernel 查看實際狀態。

Rocky 和 Alma 上哪些套件會觸發重新開機提示？

plugin 內含一份硬式編碼的清單。目前版本包含 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 資料庫比對，而容器映像中的套件不在該資料庫內，因此映像中內建的過期函式庫不會顯示。請重新建置映像並重新部署。主機端仍然重要：容器 runtime 及其共用的 kernel 都是主機套件，這些套件會被偵測到。