ESAでrepairqueueコマンドを使用したワークキュー問題のトラブルシューティング

概要

このドキュメントでは、Cisco Eメールセキュリティアプライアンス(ESA)での隠しCLIコマンドrepairqueue（隠しコマンド）の使用方法と、キューの回復を検証する方法について説明します。

問題

repairqueueコマンドを実行する理由：

• ワークキューがマウントされていないことを示すエラー。これは通常、アプライアンスの不適切な電源の再投入後またはリブート後のキュー破損が原因です。
• 既知の不具合では、回避策としてこのコマンドが必要になる場合があります（Cisco Bug ID CSCuw22284 - Email queue corrupts after a mail-processing service crash or inappropriate shutdownなど）。
• gcq.pyやキュー管理サブシステムを参照するアプリケーション障害。
• Status Detailまたはworkqueue > rateは負の数をレポートします。

• StatusまたはStatus Detailは、設定されたバウンスプロファイルのしきい値を超える最も古いメッセージ値をレポートします。

  • デフォルトのしきい値：259200秒（3日）。
  • しきい値を確認するには、bounceconfig > editと入力し、Defaultプロファイルを選択します。回線を見つけます。メッセージがハードバウンスされる前にキューに留まる最大秒数を入力してください。

repairqueueコマンドを実行しない理由：

• 遅いワークキュー処理は、キュー修復を実行する有効な理由ではありません。多くの場合、管理者は遅いワークキュー処理とキューの破損を混同します。ワークキューの遅れは、通常、サービスがシステムリソースを過剰に利用しているため、同じメッセージまたは複数のメッセージの処理が繰り返されることが原因です。このような繰り返し処理されるシナリオは、通常はrepairqueueを実行するだけでは修復できません。影響を受けるサービスの詳細なトラブルシューティングが必要です。

環境

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

• ESA、AsyncOS 11.0.0-264以降を実行するすべてのハードウェアおよび仮想アプライアンス

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼働中のネットワークで、各コマンドによる潜在的な影響を確認してから次に進みます。

次の項目に関する知識が推奨されます。

• ESAワークキューを介したシステムキャパシティ、システムモニタリング、システムの健全性、およびメッセージの全体的な処理。
• ESA全体の管理。

注：詳細については、『ESA User Guide』または『ESA GUI Online Help』を参照してください。

解決方法

CLIコマンドrepairqueueを使用しても、すべてのワークキューの問題または破損が修復されるわけではありません。ユーティリティは、ワークキューの修復をベストエフォートで試行します。

1. status detailを実行して、ワークキューに負の値やキューマウントの問題など、問題ですでに説明されている症状が表示されているかどうかを確認します。
2. workqueueを実行し、Rateオプションを選択します。報告されたレートがトリガー条件をサポートするかどうかを確認します。
3. statusまたはstatus detailのOldest Messageの値を、設定したバウンスプロファイルのしきい値と比較します。値がしきい値を超えた場合は、修復手順を続行します。

警告: repairqueueを実行すると、ワークキュー内のアクティブメッセージが失われる可能性があります。

4. repairqueueを実行します。最初のプロセスでは、続行して修復を実行する前に、権限の入力を求めるプロンプトが表示されます。

   esa.example.com> repairqueue
   
   Do you want to repair or clean the queue?
   1. Repair.
   2. Clean.
   [1]> 1
   
   The mail flow will be stopped throughout the repair/cleanup process
   WARNING:
   This utility does a best effort to repair the queue.
   Not all queues corruptions can be repaired.
   Are you sure you want to proceed? [N]> y
   Checking generation checksum files
   ...
   <<>>
   ...
   done
   Repair succeeded
   Starting Hermes
   Hermes Started
   
   Log into the system and verify the status of the system.

   注：仮想ESAでは、既知の不具合Cisco Bug ID CSCuz28415に記載されている「Waiting for the queue to mount: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory」の出力を無視します。

5. 修復プロセスが完了してワークキューが修復されると、アプライアンスは以前のワークキューの古いチェックポイントを保持します。ワークキュー処理のための新しいチェックポイントの書き込みを再開するには、repairqueueをもう一度実行し、Cleanにコマンドを入力します。

   esa.example.com> repairqueue
   
   Do you want to repair or clean the queue?
   1. Repair.
   2. Clean.
   [1]> 2
   
   The mail flow will be stopped throughout the repair/cleanup process
   WARNING:
   There is a backup found this may be the only backup.
   This will remove the old queue.
   Are you sure you want to proceed? [N]> y
   Double confirmation. Are you sure you want to proceed? [N]> y
   Removing old queue
   Cleanup finished

6. CLIからstatus detailコマンドを実行するか、GUIでMonitor > System Statusの順に選択します。システムステータスがオンラインであることを確認します。
7. メールログを確認して、メール処理を確認します。CLIから、tail mail_logsコマンドを実行します。
8. workqueueコマンドを実行し、Rateオプション（デフォルトは10秒）を選択します。 InとOutのレートが現在のメールフローに対して妥当であることを確認します。ワークキューに大きなバックログがある場合は、ドレインに時間がかかる可能性があります。

原因

ワークキューの破損の一般的な原因には、次のものがあります。

1. 予期しないリブートまたは不適切なシャットダウン（停電など）。 その時点で実行中のバックエンドプロセスによっては、キューが破損したり、再起動後にマウントに失敗したりする可能性があります。この場合、CLIは次のようなエラーを報告する可能性があります。

   esa.example.com> status
   
   Enter "status detail" for more information.
   
   Couldn't obtain mail stats - my.esa: The daemon is not responding.

   esa.example.com> status
   
   Enter "status detail" for more information.
   
   Couldn't obtain mail stats - the queue is not mounted

2. メモリ(RAM)の過剰使用。これは一般に、過剰な着信接続またはインジェクションを許可するリスナーまたはメールフローポリシーの設定に関連しています。listenerconfigを確認し、最大着信接続数が展開に適していることを確認します。

FAQ

ESAで11.0.0-264以降が実行されていない場合はどうすればいいですか。

隠しCLIコマンドrepairqueueオプションが付いていない、古いバージョンのAsyncOSを実行しているアプライアンスを使用しているユーザは、Ciscoサポートエンジニアに手順をアシストしてもらうためにサポートケースをオープンできます。サポートトンネルがオープンされ、シスコサポートがアプライアンスにアクセスしてrepairqueueコマンドを実行するために使用可能である必要があります。アクティブなサポートケースをオープンするには、シスコサポートにお問い合わせください。

ワークキューの破損はメールの損失を意味しますか。

ほとんどの場合、破損はメール損失と同じではありません。メッセージ処理に関連するメタデータがアプライアンス上にないため、キューが破損しています。これは、キュー、レポート、およびメッセージトラッキング間の処理の記録保持です。repairqueueを実行すると、ESAメタデータが再構築され、サービスと処理の間の誤った報告が消去されます。

ワークキューの破損に影響はありますか。

ESAは破損したキューで長時間実行することができ、ほとんどのメッセージは引き続き処理されます。ただし、statusコマンドの最も古いメッセージ（bounceconfigしきい値よりもはるかに古い）の値によって示されるように、アプライアンスの反応が遅く見える場合や、一部のメッセージがクリアできない場合があります。 破損したキューでAsyncOSが再起動すると、キューがマウントに失敗する場合があります。破損が早期に発生し、アプライアンスが再起動するまで認識されない場合があり、その時点でキューはマウントに失敗します。

修復スクリプトが完了するまでにどれくらいの時間がかかりますか？

ワークキューの修復には、ESAの状態や、アクティブなワークキューで現在処理中のメッセージの数によっては、10秒から数時間かかる場合があります。破損時にフルキューを使用するローエンドアプライアンスでのワークキューの修復には、数時間かかる場合があります。

修復キューを実行できない場合や完了しない場合はどうなりますか。

特定の状況（アプライアンスでのキューがいっぱいになるなど）で、repairqueueを完了できないことがあります。4時間以上経過してもrepairqueueが完了しない場合、キューは修復不可能である可能性が高く、新しいキューを作成するしかありません。このような高度な問題については、シスコサポートに連絡して、アクティブなサポートケースをオープンし、シスコサポートのサポートを依頼してください。

関連コンテンツ

• Cisco Eメールセキュリティアプライアンスエンドユーザガイド
• Cisco Eメールセキュリティアプライアンスコマンドリファレンス
• 作業キューはどのような順序で処理されますか作業キューのパイプラインとは何ですか。
• テクニカル サポートとドキュメント – Cisco Systems

更新履歴

改定	発行日	コメント
2.0	02-Oct-2026	再認定
1.0	10-Aug-2017	初版