Zimbra zmcontrolのステータスでホストサービスが停止していると表示される場合のトラブルシューティングガイド

架空の例：小規模企業のZimbraサーバーの管理者であるAlexは、定期的なホストメンテナンス期間後にWebメールが利用できなくなったという報告を受けました。サーバー上で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

出力結果を保存し、チェック時刻を記録してください。アレックスの架空のケースでは、メールボックスは停止しているものの、LDAPとMTAは実行中と報告されている点が重要です。複数のコンポーネントが停止している場合は、停止順序と、最近のアップデート、再起動、証明書の変更、ストレージイベント、構成編集が問題発生前に発生したかどうかを記録してください。マルチサーバー環境では、影響を受ける各ホストでステータスチェックを実行してください。メールボックスノード、LDAPノード、MTAノードはそれぞれ異なる役割と依存関係を持っています。

Zimbraコマンドリファレンスでzmcontrol statusは、コンポーネントの実行状態または停止状態を表示すると説明されていますが、掲載されている例は古いZCSリリースのものです。サーバー上の現在の出力が、関連するインベントリです。リリース固有の手順を適用する前に、 Zimbra zmcontrolリファレンスを参照し、カテゴリとバージョン情報を確認してください。

2. 最初の障害に関する最近のログを確認する

サービスが停止したのと同じ時刻に発生したエラーを探してください。一般的なパッケージインストールの場合、有用な場所としては/var/log/zimbra.log、およびの下にあるファイルなどが挙げられます/opt/zimbra/log。存在するログの正確な内容は、Zimbraのリリースと有効になっているサービスによって異なります。

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.logmailboxd が LDAP に接続できなかったと表示された場合は、mailboxd を繰り返し再起動するのではなく、LDAP 接続を診断することが次のステップです。Zimbra のトラブルシューティング ページには、、、、などの一般的なサーバー ログが一覧表示されており、mailbox.log問題をエスカレーションする際にはzimbra.log、時間に関連する抜粋を収集することを推奨しています。Zimbraのトラブルシューティングとログ収集に関するガイダンスを参照してください。nginx.logzmmailboxd.out

3. ホストレベルの問題を除外する

起動を試みる前に、リソースと基本的なホストIDを確認してください。これらの読み取り専用のチェックにより、一般的なオペレーティングシステムの不具合の原因を迅速に特定できます。

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

Zimbraのデータボリュームまたはログボリュームがいっぱいになった場合は、システムの通常の保持および容量管理手順に従って空き容量を確保してください。メッセージストア、データベースファイル、またはログをむやみに削除しないでください。inode数が不足すると、ファイルシステムに空き容量があるように見えても、新しいファイルの作成が妨げられることがあります。メモリ不足や異常に高い負荷も、Javaベースのメールボックスサービスが正常に起動しない原因となることがあります。

ホストの完全修飾名が、デプロイメント環境において想定どおりに解決されることを確認してください。ホスト名またはDNSレコードが変更された場合は、サーバーの構成名および他のZimbraノードと比較してください。また、最近のパッケージ更新、証明書の更新、ファイアウォールの変更、ストレージのマウント状況も確認してください。サーバーを再起動した場合は、サービスを開始する前に必要なデータボリュームがマウントされていることを確認してください。

4. 依存関係の順序でトラブルシューティングを行う

ログに表示されている、またはステータス出力で停止している最も早い依存関係から始めてください。Zimbra コンポーネントは構成と認証にディレクトリ情報を使用するため、LDAP は特に重要です。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 startZimbra ユーザーとして以下のコマンドを実行します。

su - zimbra
zmcontrol start

各コンポーネントの出力を監視してください。サービスがエラーを報告した場合はFAILED、正確なメッセージを記録し、対応するログを確認するまで同じ起動試行を繰り返さないでください。起動コマンドは有用なエラーを明らかにする可能性がありますが、繰り返し再起動すると、元の障害が隠蔽されたり、まだユーザーにサービスを提供しているコンポーネントが中断されたりする可能性があります。メンテナンス期間があり、すべてのノードへの影響を理解している場合を除き、アクティブなインシデント中に広範囲なstop、shutdownまたはrestartコマンドを実行することは避けてください。

古い wiki ページに載っているからといって、PID ファイルを削除したり、プロセスを強制終了したり、生成された Postfix 構成を変更したり、LDAP/データベース修復コマンドを実行したりしないでくださいkill -9。これらの手順は、プロセスの状態やソフトウェアのバージョンに大きく依存します。まず、プロセスが本当に孤立していることを確認し、リリース固有のベンダーの手順に正確に従い、最新のバックアップが存在することを確認してください。Zimbra の公開されているトラブルシューティング ページは、公開時期がまちまちで、アーカイブや作業中であることを明示的に記載しているものもあります。

6. ステータス出力を使用して、次のアクションを絞り込む。

• LDAPが停止し、複数のサービスが停止しました。下流のサービスを診断する前に、LDAP自身の起動ログ、DNS、ホスト名解決、データ量、およびノー​​ド間の接続性について調査してください。
• メールボックスが停止し、LDAP が実行されている場合：メールボックスのログ、ホストのメモリとディスクのチェック、およびリスナーの検査を使用して、最初の mailboxd の障害を探します。
• MTAが停止し、メールボックスが稼働中の場合： MTAログ、LDAP接続性、構成生成エラー、およびサーバーが構成済みのSMTPリスナーをバインドできるかどうかを確認してください。
• ロガー、統計情報、スパム対策、またはウイルス対策のみが停止している場合、そのコンポーネントがこのサーバー上の影響を受けるメールフローに必要かどうかを判断してください。その状態によっては、Webメールの停止の原因を説明せずに、監視やフィルタリングに影響が出る可能性があります。
• すべてのコンポーネントが「実行中」と表示されているにもかかわらず、ユーザーが接続できない場合は、 Webプロキシ、外部ロードバランサー、DNS、ファイアウォール、TLS証明書、および関連するクライアント向けエンドポイントを確認してください。「実行中」のプロセスは、クライアントがサービスにアクセスできることを証明するものではありません。

この架空の例では、LDAPとMTAが「実行中」になっているからといって、アレックスはZimbraサーバー全体が正常だと結論付けるべきではありません。メールボックスがWebメールが利用できない直接の原因である可能性もあるからです。メールボックスのログがLDAPを指しているにもかかわらず、LDAPが「実行中」の状態になっている場合は、概要ラベルだけに頼るのではなく、これらのサービス間の接続設定をテストしてください。

7. ユーザーの視点から復旧を確認する

起動試行後、zmcontrol status再度実行して、以前停止していたサービスが「実行中」と報告していることを確認してください。次に、サービスのログを確認して、新たな起動エラーがないか確認してください。正常状態であることは必須ですが、十分ではありません。管理者がWebインターフェースにアクセスできること、承認済みのテストアカウントがサインインできること、および想定されるメールフローが機能することを確認してください。MTAインシデントの場合は、新しい受信メッセージと送信メッセージが配信され、キューが拡大するのではなく縮小していることを確認してください。

アレックスの例では、復旧とは、起動後もメールボックスが「実行中」のままであり、メールボックスのログに元の依存関係やバインドエラーが表示されなくなり、テストユーザーがウェブメールにアクセスできる状態を指します。ステータスが「停止中」に戻った場合は、再起動を繰り返すのではなく、新しい起動出力と一致するログ抜粋を保存します。この証拠は、永続的な依存関係の障害と、起動後にクラッシュするプロセスを区別するのに役立ちます。

いつエスカレートすべきか

LDAPが起動しない、データベースまたはディレクトリの整合性エラーが発生する、サービスが繰り返しクラッシュする、システムが状態の不整合があるマルチノードクラスタである、または次に提案されるアクションがデータの削除または生成された構成の変更である場合は、Zimbraサポートまたはデプロイメントを担当する管理者に連絡してください。Zimbraのバージョンとビルド、オペレーティングシステムのバージョン、サーバーの役割とトポロジ、正確なzmcontrol status出力、最近の変更履歴、および障害発生時のログ抜粋を含めてください。ログを共有する前に、パスワード、秘密鍵、認証トークン、および個人メッセージの内容を伏せ字にしてください。

実際の目標は、最初に障害が発生した依存関係を特定し、バージョンに応じた修正を1つ行い、プロセスレベルとユーザーレベルの両方でサービスの動作を確認することです。このアプローチにより、メールサービスを復旧させると同時に、単一のコンポーネントの停止がより広範囲な障害に発展するリスクを軽減できます。