修正 SUSE Linux 伺服器在 systemd 關閉時重新啟動掛起的問題

如果 SUSE Linux 伺服器在重啟過程中卡在 systemd 關閉訊息處，最先想到的並非重啟指令本身有問題。大多數情況下，systemd 正在等待某個單元、掛載點、進程或關閉鉤子完成。因此，最穩健的解決方法是找出仍在運行的特定任務，檢查其無法停止的原因，並修復該元件，而不是全域縮短關閉逾時時間。

本指南通篇使用假設範例：一台名為 `<server_name>` 的伺服器lab-sles01執行 SUSE Linux Enterprise Server，並在重新啟動過程中暫停，並顯示類似 `<message>` 的訊息A stop job is running for backup.service。此範例僅用於說明診斷方法；並非真實測試報告，也不表示某個特定的 SUSE 版本在名為 `<service_name>` 的服務中有缺陷backup.service。

四步驟修復簡述

步驟 1：準確記錄關機停止的位置

在規劃重新啟動期間，請監控本機控制台、虛擬機器控制台、BMC/IPMI 控制台或虛擬機器管理程式控制台。明確指出是哪個單元發出的日誌比「systemd 凍結」之類的通用描述更有用。例如lab-sles01，假設控制台顯示某個單元backup.service仍在停止運行，而其他單元已關閉。

範例：關機控制台backup.service將 systemd 仍在等待的單元標識出來。

如果控制台顯示的是某個.mount單元、網路檔案系統、裝置或其他服務的名稱，請根據該名稱進行排查，而不是套用通用的服務逾時。控制台底部顯示的單元名稱只是一個線索，不一定是根本原因：它本身可能正在等待子進程、儲存、網路 I/O 或其他依賴項。

SUSE 目前的 systemd 指南指出，長時間重啟或斷電可能是因為某個服務未退出導致的，並建議檢查 systemd 作業。請參閱《SUSE Linux Enterprise Server 16.0：systemd 基礎知識入門》。

步驟 2：伺服器返回後使用之前的啟動日誌

機器重新啟動後，檢查剛發生的關機過程。 SUSE 會在日誌中記錄啟動偏移：boot₁0是目前啟動，boot_{2 -1} 上一次啟動，依此類推。首先檢查：

sudo journalctl --list-boots
sudo journalctl -b -1

對於篇幅較長的期刊，反向排序可以更快顯示最後幾篇期刊文章：

sudo journalctl -b -1 -r

範例：上一次啟動日誌顯示假設的備份服務收到 SIGTERM 訊號，隨後逾時。

尋找諸如Stopping“ stop job，，，，，，”之類的短語，或來自可疑服務本身的訊息。一旦知道設備名稱，就可以縮小搜尋範圍timed out：Failed with resultUnmountingDependency failed

sudo journalctl -b -1 -u backup.service

SUSE在其SLES 15 SP7 日誌文件journalctl -b -1中提供了先前啟動分析的相關說明。如果日誌中不包含先前的啟動記錄，請勿根據缺失的歷史記錄隨意得出結論；請檢查 journald 儲存的配置，並在下次重現問題時使用控制台或遠端日誌記錄。journalctl --list-boots

步驟 3：確定阻塞物是服務、掛載點、抑制器或延遲關閉鉤子

如果能在維護視窗期內重現問題，請保持第二個管理控制台可用。在連線中斷之前，執行以下命令：

sudo systemctl list-jobs
sudo systemctl status backup.service

範例：backup.service正在執行停止作業，而重啟目標則在其後等待。

上游 systemd 偵錯指南解釋說，顯示為 `<jobs_name>` 的作業running必須先完成，顯示為 `<dependency_jobs_name>` 的依賴作業waiting才能繼續進行。 SUSE 也建議systemctl list-jobs在關機或重新啟動耗時過長時執行此操作。因此，當伺服器未完全凍結且 PID 1 仍然會回應時，此命令尤其有用。

如果服務停止得太慢

檢查單元定義及其關閉行為：

sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b

檢查該服務是否有ExecStop=操作，其進程是否處理 SIGTERM 訊號，以及是否正在等待儲存或網路資源。資料庫、備份代理或中間件服務可能需要一些時間來刷新數據，因此提前終止它並不能自動解決問題。

如果涉及掛載點或網路檔案系統

尋找卸載操作失敗的情況，並確定掛載點：

findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'

對於 NFS 或 CIFS，請檢查伺服器可達性、過期會話以及掛載選項是否符合伺服器的關機要求。如果阻塞單元是由/etc/fstab某個特定服務產生的，請修正該掛載配置，而不是將特定於服務的逾時套用於無關的單元。

如果重啟請求被抑制

在關機開始之前，您可以列出正在運行的 systemd 抑制劑：

systemd-inhibit --list

抑制鎖可以阻止或延遲應用程式執行不應被中斷的任務時的關機請求。當重啟請求本身在系統進入最終關機序列之前被延遲時，抑制鎖的作用最為顯著。請參閱上游systemd-inhibit 手冊。

如果掛起發生在服務已經停止之後

如果系統在後期出現掛起，則需要進行不同的調查。 systemd 會/usr/lib/systemd/system-shutdown/在最終重新啟動或關機前不久運行一些可執行文件，並等待它們完成。如果日誌和控制台顯示常規服務已經停止，而掛起發生在最終關機階段，請檢查目錄以及任何供應商安裝的鉤子。上游systemd 關閉服務文件對此行為進行了描述。

步驟 4：修復組件，然後測試正常重新啟動。

回到之前的假設場景lab-sles01。假設日誌顯示，backup.service服務在備份程序完成後仍然忽略正常的終止操作。首先，需要修復服務本身或其停止命令。如果已知服務在一段有限的時間內可以安全終止，則可以透過單一服務進行 systemd 覆蓋來限制 systemd 的等待時間。

建立覆蓋而不是編輯供應商單元/usr/lib/systemd/system：

sudo systemctl edit backup.service

例如：

[Service]
TimeoutStopSec=30s

然後重新載入systemd的單元配置：

sudo systemctl daemon-reload

舉例說明：只有在確定某個假想服務是阻塞者之後，才會套用針對每個服務的逾時機制。

不要盲目照搬 30 秒的超時時間。適當的超時時間取決於實際服務需要安全完成的操作。對於資料庫、儲存守護程式、叢集服務或備份進程，縮短逾時時間可能會中斷正常的清理工作。逾時是一種安全措施，不能取代修復故障ExecStop=操作或無法正確終止的應用程式。

如果您對變更滿意，請測試正常重新啟動：

sudo systemctl reboot

機器恢復後，再次查看先前的啟動情況，並確認設備已正常停止，而不是僅從控制台中消失。

何時應該使用強制重啟？

強制重啟是一種恢復選項，而非故障排除策略。上游 systemd 文件指出，強制重啟--force會systemctl reboot跳過正常的服務關閉流程，但仍會終止進程並嘗試以唯讀方式卸載或重新掛載檔案系統。重複執行--force此操作更加危險，因為它可能在未終止進程或卸載檔案系統的情況下重啟，從而存在資料遺失的風險。

如果伺服器已經卡死，並且沒有更安全的恢復服務的方法，那麼根據您的操作規程，強制重啟一次可能是合理的：

sudo systemctl reboot --force

避免將systemctl reboot --force --force虛擬斷電重啟或實體重啟視為常規修復手段。這些操作可能會清除所需證據，並危及正在進行的寫入作業。上游systemctl 文件明確區分了單次強制斷電和雙次強制斷電行為。

如果每次重開機都卡住，而且無法在正常模式下進行故障排除怎麼辦？

使用維護控制台啟動進入救援模式。 SUSE 文件介紹如何systemd.unit=rescue.target透過 GRUB 編輯器為核心命令列新增命令。救援模式提供對本機檔案系統和核心服務的 root 權限，同時保持網路連線處於非活動狀態，這有助於您停用或修復出現問題的服務或掛載設定。

請參閱SLES 15 SP7 管理指南，以了解官方的救援模式操作步驟。如果問題僅在特定軟體包、核心、驅動程式或儲存變更後出現，請在進行永久性逾時變更之前，請查看相關的 SUSE 維護記錄。

快速決策表

結論

對於在 systemd 關閉過程中卡住的 SUSE Linux 伺服器，持久的解決方法是找出 systemd 正在等待的作業，並修復該單元或其相依性。記錄關閉訊息，檢查journalctl -b -1並systemctl list-jobs隔離systemctl status阻塞來源，然後僅更改每個服務的逾時或掛載配置。強制重啟方法應僅用於恢復情況，而非日常操作。