診斷卡在 systemd 關閉螢幕的 SUSE 伺服器

如果 SUSE Linux Enterprise Server 在 systemd 關閉過程中掛起，請找出正在執行停止作業的單元，或檢查上次啟動的最後訊息，然後修復該單元或其相依性。單元是指 systemd 管理的資源，例如服務或掛載點；停止作業是 systemd 請求關閉某個單元的指令。不要先嘗試降低全域逾時時間或強制斷電，因為服務或檔案系統可能仍在關閉檔案或寫入資料。

本演練遵循 2026 年 10 月查閱的 SLES 15 SP7 文件。具體的停止策略取決於服務和儲存供應商，因此請根據他們的指導進行任何特定於設備的變更。

1. 安全觀察關機過程

第一步：記錄確切的訊息，並等待有用的證據。

如果控制台顯示「正在執行停止作業，等待…」並附有倒數計時，請記下指定的服務或掛載點以及倒數計時是否有變更。這表示 systemd 正在等待該單元的停止操作，並不一定意味著作業系統崩潰；資料庫和遠端儲存可能需要一些時間才能正常關閉。

透過遠端控制台、串列埠控制台或其他可用終端進行觀察。寫入操作進行期間，請避免執行重設或電源指令。如果系統停止回應，請記錄最後可見的一行，並在系統啟動後繼續操作。

2. 找到正在等待的單元

步驟 2：檢查 systemd 作業，確認機器是否仍接受指令

如果 SSH 或第二個終端仍然有效，請詢問 systemd 哪些作業正在運作或等待，然後檢查螢幕上顯示的單元名稱：

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

請替換SERVICE為實際的單元名稱。正在執行的停止作業可以縮小搜尋範圍，但無法解釋為何進程沒有退出。更改配置前，請先查看其狀態和日誌。如果 systemd 不再回應，請勿盲目取消作業；主機復原後，請檢查先前的日誌。

3. 利用之前的啟動情況來確定原因

步驟 3：閱讀前一個靴子日誌的結尾部分。

日誌是 systemd 的核心、服務和系統訊息的索引日誌。下次成功啟動後，列出已記錄的啟動程序並檢查上一次啟動的結尾：

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

尋找最後一條「正在停止」訊息、逾時、重試記錄或指定的設備或掛載點。最後一行只是一個線索：關機順序可能會導致後面還有其他設備等待。比較時間戳記和附近的訊息。

步驟 4：篩選可疑服務的日誌

當螢幕或日誌中出現服務名稱時，僅查詢該單元先前啟動的條目。同時檢查其已載入的配置：

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

檢查是否存在自訂腳本ExecStop、無限期等待的腳本、未關閉的子進程或應用程式關閉鉤子中的錯誤。對於供應商提供的單元，請在編輯前將軟體包和配置與官方指南進行比較。

第五步：僅當證據指向安裝點和儲存位置時才檢查它們。

如果日誌中提到了掛載點、裝置或遠端檔案系統，請檢查掛載表以及以下位置的符合條目/etc/fstab：

sudo findmnt --verify --verbose

檢查 NFS、CIFS、iSCSI 或其他遠端相依性在關機期間是否可存取且符合預期。僅在確認不再使用後才刪除過時的掛載點。不要僅因重啟緩慢而強制卸載正在運行的檔案系統。

4. 找出並解決根本原因，不要掩蓋。

步驟 6：修復服務或僅調整其已記錄的停止策略

對於無法啟動的服務，請先修復其關閉腳本、應用程式設定或軟體包問題。每個單元的替換配置無需編輯供應商文件sudo systemctl edit SERVICE.service即可儲存。 SUSE 文件中提供了服務啟動或停止的說明；請為此工作負載使用供應商認可的值。/etc/systemd/system/TimeoutSec

完成已記錄的編輯後，使用 `systemd -r` 指令重新載入 systemd 的單元定義sudo systemctl daemon-reload，並使用 `systemd -r` 指令檢查結果sudo systemctl cat SERVICE.service。較長的超時時間可以讓正常的關機完成，但也可能延長失敗的重新啟動時間。較短的超時時間可能會在服務刷新狀態之前將其終止。不要為了掩蓋某個單元的缺陷而更改全域預設值。

步驟 7：保存日誌以備下次事件發生時使用。

/run/log/journal/SLES預設將日誌資料儲存在某個位置，該暫存目錄會在重新啟動時清除。如果journalctl -b -1目錄沒有任何先前的啟動記錄，請啟用持久性日誌儲存以便將來進行診斷：

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

持久性日誌會佔用檔案系統空間/var；SUSE 指出，預設情況下，日誌可能會佔用該檔案系統高達 10% 的空間。請檢查可用空間和保留策略，尤其是在小/var卷上。

5. 確認下次計畫重啟時間

步驟 8：確認停止操作已完成，伺服器已恢復運作

一旦疑似問題原因得到解決，安排一次可控重啟，並確保控制台存取權限可用。機器重新啟動後，檢查上次啟動的最後訊息，並確認服務的當前狀態：

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

當伺服器在未等待相同單元的情況下關機、正常啟動且服務或掛載點正常運作時，問題即可解決。如果日誌突然結束或顯示核心、控制器或硬體錯誤，請保留日誌並與 SUSE 或硬體供應商聯繫進行調查，而不是調整逾時設定。

有關命令詳情，請參閱SLES 15 SP7 systemd 指南和 SUSE 的持久日誌和 journalctl 過濾器指南。這些步驟可以識別可能的阻塞因素；正確的服務、檔案系統或硬體修復方案取決於機器本身日誌中指定的單元。