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-12，兩者的 BaseOS 套件庫都提供 dnf 4.20.0，以及 dnf-plugins-core 4.7.0 和 yum-utils，但沒有 dnf5 套件。因此，其中的 needs-restarting 是本頁說明的相同 dnf-plugins-core 外掛程式，以下內容全部適用。這也包括 -r；它會產生重新啟動提示及其結束碼，因此請保留在指令碼中。Rocky 和 Alma 9 提供較舊的 dnf-plugins-core 4.3.0 組建；兩個組建行為不同的少數情況會在下文標示。

第 1 層：需要重新開機的更新

先執行重新開機檢查。它只會讀取 RPM 資料庫與系統開機時間，不會讀取其他資料，因此速度很快，也不需要 root。

needs-restarting -r

自上次開機以來沒有重要變更時，會輸出 2 行：

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

觸發需要重新開機結果的套件，是外掛程式內硬式編碼的短清單。在 Rocky Linux 10 與 AlmaLinux 10 發布的版本中，清單包含 kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon 和 microcode_ctl。Rocky 與 Alma 9 的版本包含相同清單，但不含 kernel-core；這與下一節說明的原因有關。請檢查自己的清單，不要直接假設。

清單中的每個項目都有明確原因。新的 kernel 套件只會將檔案寫入 /boot 與 /lib/modules，而正在執行的核心無法在自身執行期間被替換，因此必須等到重新開機後才會生效。系統中幾乎所有使用者空間程序都會連結 glibc，包括 PID 1。這表示「重新啟動受影響的服務」也會包含重新啟動 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 安裝時間，並與系統開機時間比較。如果核心套件是在上次開機後安裝，結果就會是「需要重新開機」。系統會在可用時透過 D-Bus 從 systemd 的 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 下次會選取的核心。如果這 3 項資訊不一致，請先修正開機預設值，再重新開機無法透過主控台連線的機器。

Rocky 和 Alma 9 另有一項缺口。由於它們的 plugin build 會監看 kernel，但不會監看 kernel-core，因此只更新 kernel-core 而未更新 kernel 套件的交易，會留下已安裝但尚未執行的新核心；此時 needs-restarting -r 仍會回報不需要重新開機。Red Hat 已針對 Enterprise Linux 9 記錄這項行為。在已安裝 kernel 套件的機器上執行一般的 dnf update 也會一併更新該套件，因此仍會觸發提示。請執行 rpm -q kernel 進行檢查。如果結果顯示該套件未安裝，這台機器上的重新開機提示就無法偵測核心更新；此時應改為比較 uname -r 與 rpm -q --last kernel-core。

第 2 層：需要重新啟動服務的更新

當 RPM 取代共用程式庫時，會解除舊檔案的連結並寫入新檔案。已經對應舊檔案的程序會繼續保留舊 inode，並執行舊程式碼。openssl-libs 是最需要注意的情況：libcrypto 中的修正，必須等網頁伺服器重新啟動後才會套用。

sudo needs-restarting -s

這會列出自身檔案，或相依元件檔案在服務啟動後曾更新的 systemd 服務。請使用 sudo。如果沒有 root 權限，此工具只能讀取自己程序的 /proc 項目，因此會靜默少報，讓較短的清單看起來像是好消息。

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

第一個指令會列出每個受影響程序的 PID 和命令列。第二個指令會排除 systemd 服務已涵蓋的程序，留下登入 shell、tmux 工作階段、cron 工作，以及你手動啟動的程序。這些程序都不會自行重新啟動。--exclude-services 僅存在於 Rocky 和 Alma 10 build。9 沒有這個選項，因此請讀取完整的 sudo needs-restarting 清單，並根據 -s 輸出，排除屬於服務的程序。

如果清單中的服務屬於需要重新開機的套件，例如 dbus-broker.service，不要重新啟動該服務。請改為重新開機。截至 2026-10-12，Rocky Linux 和 AlmaLinux 發布的 build 仍會像列出其他服務一樣列出這類服務。CentOS Stream 10 套件在 2026 年 7 月加入了變更，會將這些服務從清單移除，並改在 stderr 輸出 Warning: The following services should not be restarted but require a reboot:。當你的版本包含這項變更後，請依照警告的字面意義處理。

其餘服務請一次重新啟動一個，並在處理下一個之前確認目前服務正常。

sudo systemctl restart nginx
systemctl status nginx

不要將清單直接 pipe 給 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 的用途；在 9 上則使用單純的 sudo needs-restarting。

為何使用 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 傳回了退出碼 1。此退出碼表示「需要重新開機」，因此應依此分支處理，不要讓它直接終止指令碼。
• 程式庫更新後，needs-restarting -s 通常沒有任何輸出，表示執行時未使用 sudo。沒有 root 權限時，它只能看到目前帳號的程序。
• needs-restarting -r 顯示不需要重新開機，但 uname -r 顯示的版本比已安裝的最新 kernel 舊，通常表示系統是以較舊的 kernel 開機。此檢查會比較安裝時間與開機時間，而這兩個時間點都已經早於目前時間。請查看 grubby --default-kernel。在 Rocky 或 Alma 9 上，還有第二種原因：更新修改了 kernel-core，但未安裝 kernel 套件；9 build 不會監控該項目，因此仍需要重新開機。
• needs-restarting --exclude-services 顯示 unrecognized-argument 錯誤，表示您使用的是 9 build，而該版本沒有此選項。請直接使用 sudo needs-restarting。
• 某項服務在您重新啟動幾分鐘後，下一次執行時又再次出現，通常表示有其他程式正在重新啟動它，或該 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 啟動，安裝時間就會早於開機時間，檢查結果也不會提出警告。在 Rocky 和 Alma 9 上，若未安裝 kernel 套件而更新 kernel-core，也會漏判，因為 9 版組建的清單中沒有 kernel-core。執行 uname -r、rpm -q --last kernel 和 sudo grubby --default-kernel，即可查看實際狀態。

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

外掛程式內有一份寫死的清單。在 Rocky 和 Alma 10 上，清單包含 kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon 和 microcode_ctl。在 9 上則是相同清單，但不包含 kernel-core。你可以擴充清單：將 .conf 檔案放入 /etc/dnf/plugins/needs-restarting.d/，每行寫入一個套件名稱，這些名稱也會納入重新開機判斷。

dnf-automatic 能自行重新啟動伺服器嗎？

可以。在 /etc/dnf/automatic.conf 的 [commands] 區段中設定 reboot = when-needed，只有在它套用的交易需要重新開機時才會重新啟動伺服器。when-changed 會在任何套件變更後重新開機，而 never 是預設值。reboot_command 控制重新開機方式；預設設定會向已登入的使用者發出 5 分鐘前的警告。只有在能夠復原該機器的開機流程時才啟用此功能，因為無人值守地重新啟動無主控台存取權限的 VPS，可能導致嚴重故障。

needs-restarting 能偵測容器內的程序嗎？

無法有效偵測。它會將執行中的程序與主機的 RPM 資料庫比對，而容器映像檔內的套件不在該資料庫中，因此映像檔內預先封裝的過期函式庫不會顯示。請重新建置映像檔並重新部署。主機端仍然重要：容器執行階段與容器共用的 kernel 都是主機套件，也會被偵測到。