Zimbra zmcontrol 狀態顯示主機服務已停止：故障排除指南

假設範例： Alex 是一家小型公司 Zimbra 伺服器的管理員，在例行主機維護視窗結束後，他收到報告指出 Webmail 無法存取。 Alex 在伺服器上執行指令後zmcontrol status發現mailbox Stopped，LDAP 和 MTA 顯示正常Running。這只是一個範例場景，並非實際故障或測試報告。首要步驟是在重新啟動整個服務堆疊或刪除檔案之前，找到故障元件的啟動錯誤。

zmcontrol status報告已安裝的 Zimbra 主機識別的服務狀態。服務停止只是症狀，並非診斷結果：原因可能是檔案系統已滿、相依性失敗、連接埠衝突、進程崩潰或特定版本的問題。服務名稱和角色會因 Zimbra 版本以及單一伺服器或多伺服器部署而異。 Zimbra 技術中心提供的命令參考資料包含較舊和已存檔的內容，因此請將其用於基本了解，並根據已安裝版本的文件或支援資訊驗證任何修正操作。本指南已於 2026 年 10 月 6 日根據 Zimbra 官方參考資料進行核對。

1. 在變更任何內容之前，請記錄已停止的功能。

登入受影響的 Zimbra 主機，切換到 Zimbra 作業系統用戶，並記錄產品版本和完整狀態輸出：

su - zimbra
zmcontrol -v
zmcontrol status

儲存輸出結果並記錄檢查時間。在 Alex 的假設案例中，關鍵細節是郵箱已停止，但 LDAP 和 MTA 顯示正在運作。如果多個元件停止，請記錄它們的停止順序，以及最近的更新、重新啟動、憑證變更、儲存事件或設定編輯是否先於此問題發生。在多伺服器部署中，請在每個受影響的主機上執行狀態檢查；郵件節點、LDAP 節點和 MTA 節點具有不同的角色和相依性。

Zimbra 指令參考文件中描述該指令zmcontrol status會顯示元件的「運行中」或「已停止」狀態，但其列出的範例來自較舊的 ZCS 版本。您伺服器上的目前輸出才是相關的清單。請參閱Zimbra zmcontrol 參考文檔，並在應用特定版本的操作步驟之前，檢查其類別和版本資訊。

2. 檢查最近的日誌，找出第一次故障

尋找服務停止時出現的錯誤。對於典型的軟體包安裝，有用的位置包括 `/etc/ zimbra /var/log/zimbra.log/config .../opt/zimbra/log

sudo tail -n 200 /var/log/zimbra.log
tail -n 200 /opt/zimbra/log/mailbox.log
tail -n 200 /opt/zimbra/log/zmmailboxd.out

請使用具有檔案讀取權限的帳戶執行命令；sudo僅在必要時使用。尋找最早出現的具體錯誤，而不僅僅是重複出現的「服務已停止」訊息。例如，「裝置上沒有剩餘空間」、綁定或位址正在使用錯誤、LDAP 連線失敗、資料庫連線失敗、權限錯誤或 Java 程序退出。後續的一系列故障可能僅僅反映了早期某個依賴項的故障。

對於 Alex 來說，如果mailbox.log顯示 mailboxd 無法連線到 LDAP，下一步是診斷 LDAP 連線問題，而不是重複重新啟動 mailboxd。 Zimbra 的故障排除頁面列出了常見的伺服器日誌，包括 `<log_name>` mailbox.log、zimbra.log` nginx.log<log_name>`、`<log_name>` 和`<log_name> zmmailboxd.out`，並建議在升級問題時收集與時間相關的日誌摘錄。請參閱Zimbra 的故障排除和日誌收集指南。

3. 排除主機層面的問題

嘗試啟動之前，請檢查資源和基本主機身分。這些只讀檢查可以快速發現常見的作業系統原因：

df -h /opt/zimbra /var/log
df -i /opt/zimbra /var/log
free -h
uptime
hostname -f
timedatectl status

如果 Zimbra 資料磁碟區或日誌磁碟區已滿，請透過系統正常的保留和容量管理流程釋放空間；切勿盲目刪除郵件儲存、資料庫檔案或日誌。即使檔案系統看起來有可用容量，inode 計數耗盡也可能導致無法建立新檔案。記憶體不足或異常高的負載也可能導致基於 Java 的郵箱服務無法可靠啟動。

確認主機的完全限定網域名稱 (FQDN) 解析是否符合部署預期。如果主機名稱或 DNS 記錄發生更改，請將其與伺服器配置的名稱以及其他 Zimbra 節點進行比較。同時，檢查最近的軟體包更新、憑證續約、防火牆變更和儲存掛載情況。如果伺服器已重啟，請在啟動服務之前驗證所需的資料磁碟區是否已掛載。

4. 依依賴關係順序進行故障排除

首先檢查日誌中顯示最早的依賴項或狀態輸出中已停止的依賴項。 LDAP 尤其重要，因為 Zimbra 元件使用目錄資訊進行設定和驗證。如果 LDAP 發生故障，即使下游服務本身的檔案和進程看起來完好無損，也可能導致服務失敗。檢查 LDAP 相關條目zimbra.log，確認主機解析和節點間連線正常，並驗證 LDAP 資料磁碟區是否已掛載且可寫入。切勿嘗試根據通用檢查清單進行資料庫還原或重建目錄資料；這些操作可能會導致資料遺失，並且必須與產品版本和備份狀態相符。

如果 LDAP 運作正常但mailbox已停止，請進行檢查mailbox.log。zmmailboxd.out檢查磁碟空間、可用內存，以及是否有其他進程佔用了 mailboxd 所需的連接埠或位址。管理者可以使用以下命令檢查監聽套接字：

sudo ss -ltnp

將輸出結果與此安裝中配置的連接埠進行比較。切勿僅僅因為歷史故障排除頁面提到連接埠衝突就停止無關的 Web 伺服器；請先確定該進程並確認停止它是安全的。 Zimbra 的舊版郵箱故障排除頁面記錄了一種郵箱啟動失敗模式，但已將其標記為已存檔且不再支援最新版本。請將其視為症狀範例，而非通用的修復步驟：已存檔的 Zimbra 郵箱故障排除說明。

如果mta郵件傳輸服務停止執行，請檢查郵件傳輸錯誤zimbra.log，並確認 MTA 主機可以存取其配置的 LDAP 服務。 MTA 的職責包括接收和轉發郵件，在郵件無法投遞期間，排隊的郵件可能會保持延遲狀態。請僅在確認適用於您版本的相應命令後才檢查佇列；切勿在出現問題時立即刷新、刪除或重新排隊郵件。 Zimbra 的 MTA 概述解釋了 Postfix、LDAP 以及傳入佇列、活動佇列、延遲佇列和保留佇列之間的關係：Zimbra MTA 架構和佇列概述。

5. 嘗試受控啟動

一旦您收集到證據並修正了已識別的主機級原因，請使用您安裝的版本和伺服器角色支援的命令啟動服務。在標準的 Zimbra Collaboration 安裝中，管理員通常zmcontrol start以 Zimbra 使用者身分執行：

su - zimbra
zmcontrol start

密切注意每個組件的輸出。如果某個服務報告錯誤FAILED，請記錄確切的錯誤訊息，並在檢查對應的日誌之前停止重複嘗試啟動。啟動命令可以暴露有用的錯誤，但重複重新啟動可能會掩蓋原始故障或中斷仍在為使用者提供服務的元件。除非您有維護視窗並且了解對每個節點的影響，否則請避免在故障發生期間運行廣泛的stop、shutdown或命令。restart

不要kill -9因為某個舊的維基頁面列出了某些操作就刪除 PID 檔案、終止進程、修改產生的 Postfix 設定或執行 LDAP/資料庫修復命令。這些步驟高度依賴於進程狀態和軟體版本。首先要確認進程是否確實已孤立，然後嚴格遵守特定版本的供應商流程操作，並確保存在最新的備份。 Zimbra 的公開故障排除頁面發佈時間不一，有些頁面明確標有存檔或正在更新的聲明。

6. 利用狀態輸出縮小下一步操作的範圍

LDAP 停止運行，多個服務停止運行：在診斷下游服務之前，請調查 LDAP 本身的啟動日誌、DNS、主機名稱解析、資料量和節點間連接。
郵箱已停止，LDAP 正在運行：使用郵箱日誌、主機記憶體和磁碟檢查以及監聽器檢查來查找第一個 mailboxd 故障。
MTA 已停止，郵箱正在執行：檢查 MTA 日誌、LDAP 可達性、設定產生錯誤，以及伺服器是否可以綁定已設定的 SMTP 偵聽器。
僅日誌記錄器、統計資料、反垃圾郵件或防毒程式停止運作：請確定該元件是否是此伺服器上受影響郵件流所必需的。其狀態可能會影響監控或過濾，但不能解釋網頁郵件中斷的原因。
所有元件均顯示“正在運行”，但使用者仍然無法連線：請檢查 Web 代理程式、外部負載平衡器、DNS、防火牆、TLS 憑證以及相關的用戶端端點。進程「正在運行」並不代表客戶端可以存取該服務。

在假設的範例中，Alex 不應僅僅因為 LDAP 和 MTA 都處於運行狀態就斷定整個 Zimbra 伺服器運作正常；郵箱仍然是導致 Webmail 無法使用的直接原因。如果郵箱日誌指向 LDAP（即使其狀態為「運行中」），則應測試這些服務之間已配置的連接，而不僅依賴摘要標籤。

7. 從使用者角度確認恢復狀況

嘗試啟動後，zmcontrol status再次運行並確認先前停止的服務顯示「正在運行」。然後檢查服務本身的日誌，查看是否有新的啟動錯誤。服務狀態顯示「成功」是必要的，但還不夠：請驗證管理員是否可以存取 Web 介面，授權的測試帳戶是否可以登錄，以及預期的郵件流是否正常運作。對於 MTA 故障，請確認新的入站和出站郵件是否已送達，以及佇列是否正在減少而不是成長。

以 Alex 的範例為例，恢復意味著郵箱在啟動後保持「正在運行」狀態，郵箱日誌不再顯示原始的依賴項或綁定錯誤，並且測試使用者可以存取網頁郵件。如果狀態恢復為“已停止”，則保留新的啟動輸出和匹配的日誌摘錄，而不是循環重新啟動。這些證據有助於區分持續的依賴項故障和啟動後崩潰的進程。

何時升級

如果 LDAP 無法啟動、出現資料庫或目錄完整性錯誤、服務重複崩潰、系統是狀態不一致的多節點集群，或者下一步建議的操作涉及刪除資料或更改生成的配置，請聯絡 Zimbra 支援或負責部署的管理員。請提供 Zimbra 版本和內部版本號、作業系統版本、伺服器角色和拓撲結構、完整的zmcontrol status輸出資訊、最近的更改歷史記錄以及涵蓋故障時間段的日誌摘錄。共享日誌前，請務必隱藏密碼、私鑰、驗證令牌和個人訊息內容。

實際目標是找出第一個故障依賴項，進行一次版本相關的修正，並在進程層級和使用者層級驗證服務行為。這種方法有助於恢復郵件服務，同時降低單一元件停止運作導致更大範圍服務中斷的風險。