目次

概要

前提条件

要件

使用するコンポーネント

問題

コマンド repairqueue の使用方法

確認

FAQ

ESA 何が 11.0.0-264 をまたはより新しい実行していませんか。

workqueue "破損」平均は損失を郵送しますか。

workqueue 破損にあらゆる反響がありますか。

どんな原因が破損を並べますか。

どの位修理スクリプトは完了するために奪取 する必要がありますか。

repairqueue が動作できなければ起こりましたりまたはない完全何がか。

関連情報

概要

この資料はこれが Cisco E メール セキュリティ アプライアンス（ESA）の CLI からコマンド発行されるとき発生するアクションおよび非表示 CLI コマンド repairqueue の使用方法を記述したものです。

前提条件

要件

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

- ESA workqueue を通したメッセージのシステム 容量、システム モニタリング、システム状態および全体の処理。

- 全面的な ESA 管理。

注: 更に詳しい情報については ESA GUI からの ESA ユーザガイドかオンライン ヘルプを参照して下さい。

使用するコンポーネント

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

- ESA、すべてのハードウェアおよび AsyncOS 11.0.0-264 をまたはより新しい実行するバーチャル アプライアンス

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

問題

repairqueue コマンドを実行する原因:

- workqueue がマウントされないことを示すエラー。 これは通常アプライアンスのキュー 破損後不適当な電源の再投入または再度ブートするの結果です。

- 既知の障害は回避策としてこれを必要とします（CSCuw22284 のような-電子メール キューは hermes がまたは不適当なシャットダウン クラッシュした後）破損します。

- 「gcq.py」を参照するそれらのようなアプリケーション エラー、か待 ち 行列管理サブシステム。

- ステータス詳細か workqueue > 比率は負数を報告しています。

- ステータスか跳ね上がりプロファイルより古いステータス Detail レポート「以前のメッセージ」。 これのデフォルト値は 3 日です。 bounceconfig > Edit から確認し、既定値 の プロファイルを選択できます。 「入力します秒の最大数を探します メッセージがデフォルトで 259200 秒である、または 3 日かもしれないハードに跳ねられた」行であることの前にキューにとどまる。 これは仮想 な配信ドメインを、the.cpq.queue のような the.<destination>.queue、the.euq.queue、the.cpq.release.host 除きます。

repairqueue コマンドを実行しない原因:

- 遅い workqueue 処理はキュー 修理を実行する正当な理由ではないです。 管理者は頻繁にキュー 破損として処理する遅い workqueue を混同します。 遅い workqueue は通常システム リソースの過度の使用を保守すること当然の同じメッセージの処理を繰り返して当然です。 多くの場合繰り返されるこれらはシナリオを処理して repairqueue を単に実行することによって修理される事柄ではないです。 メッセージが処理の間に必要となる「ハングする」ことサービスのトラブルシューティングを促進して下さい。

コマンド repairqueue の使用方法

CLI コマンド repairqueue を実行することはすべての workqueue 問題か破損を修理しないかもしれません。 このユーティリティは workqueue を修理するための最もよい努力をします。

警告： ESA 管理者はそこにです workqueue からのアクティブメッセージを失う可能性メモを奪取 する必要があります。

repairqueue を実行するとき、最初のプロセス実行は権限のために続行し、修理を実行するために一度プロンプト表示します:

myesa.local> repairqueue

Do you want to repair or clean the queue?

1. Repair.

2. Clean.

[1]> 1

The mail flow will be stopped through out 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

...

<<<SNIP FOR BREVITY>>>

...

done

Repair succeeded

Starting Hermes

Hermes Started

Log into the system and verify the status of the system.

注: バーチャル ESA で、次の出力を、既知の障害（CSCuz28415）無視して下さい: 「マウントするためにキューを待っています: デバイスをか /dev/ipmi/0 または /dev/ipmidev/0 は /dev/ipmi0 で使用可能にすることができませんでした: No Such File or Directory」

修理 プロセスが完了すれば、workqueue はアプライアンスがまだ前の workqueue の古いチェックポイントを保つどんなに、修理されます。 処理する workqueue のために新しいチェックポイントを書くことを再開するために repairqueue を再度実行し、きれいになるためにコマンドを発行して下さい:

myesa.local> repairqueue

Do you want to repair or clean the queue?

1. Repair.

2. Clean.

[1]> 2

The mail flow will be stopped through out the repair/cleanup process

WARNING:

There is a backup found this may be the only backup.

This will to 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

確認

repairqueue が完了したら、workqueue を検証するために次のそれぞれをもどって来ますオンラインすればアプライアンスはメールを処理しています:

1. CLI からステータス detail コマンドを実行することによってシステム状態、かモニタ > GUI からのシステム状態を確認して下さい。  アプライアンスはオンラインのシステム状態を示す必要があります。

2. メールを予想通り処理するメールを保証するためにログオンしますアプライアンスを検討して下さい。  これは末尾 mail_logs コマンドの実行によって CLI から堪能である場合もあります。

3. 10 秒のデフォルト率と比率 オプションを選択する CLI から workqueue コマンドを実行して下さい。 アプライアンスがメールおよび/またはメールを処理している限り、比率は毎 10 秒「イン/アウト」比率のためにかなり等しいはずです。 workqueue の処理迄の大きいのがあるアプライアンスは workqueue を空にするのに時間をかけるかもしれ正常な処理を再開します。

FAQ

ESA 何が 11.0.0-264 をまたはより新しい実行していませんか。

AsyncOS のより古いバージョンを実行する repairqueue 非表示 CLI コマンド オプションがないアプライアンスを持っている顧客は Ciscoサポート エンジニア援助があるためにサポート ケースをオープンする必要があります。  サポート トンネルはアプライアンスにアクセスし、修理 キュー プロセスを実行するために開かれ、Ciscoサポートのために利用可能である必要があります。  アクティブなサポート ケースをオープンするために Ciscoサポートに連絡して下さい。

workqueue "破損」平均は損失を郵送しますか。

ほとんどの場合、破損はメール損失に匹敵しません。 キューはメッセージ 処理に関するアプライアンスにもはやないメタデータによる破損です。 これはキューとレポートの間で、メッセージ トラッキング処理するです、簿記 repairqueue を実行する等はサービスと処理の間で誤って報告する ESA メタデータおよび一掃を再製します。

workqueue 破損にあらゆる反響がありますか。

ESA は破損したキューで長い間動作でき、ほとんどのメッセージはうまく処理するアプライアンスは緩慢なようであるかもしれませんまたはある特定のメッセージは status コマンドの「以前のメッセージ」によって示されるように決して、クリアするかもしれません --- bounceconfig よりかなり古い割り当てるべきです。 AsyncOS が破損したキューで実際に再起動するとき、キューはマウントできないかもしれないしまたはそうではないかもしれません。 しばらく前に発生する、アプライアンスが再起動する、それはキューをマウントすることができませんまで罰金のようです。

どんな原因が破損を並べますか。

「キュー 破損」の 2 つのもっとも一般的な原因は次のとおりです:

1. アプライアンスの予想外リブート。 どんなバックエンド プロセスが破損するその時にしていたか電源割り込みか電源ボタンを維持することは不適当なシャットダウンという結果に終り、によってキューを、かもしれません。 アプライアンスは回復 し、キューは破損した戻って来るかもしれません、またはキューは再度ブートするに搭載可能ではないかもしれません。 これが本当である場合、ESA 管理者はステータスを CLI から実行するとき」を応答しない「キュー マウントされなかった」アラートや「デーモン見ます。

myesa.local> status

Enter "status detail" for more information.

Couldn't obtain mail stats - my.esa: The daemon is not responding.

myesa.local> status

Enter "status detail" for more information.

Couldn't obtain mail stats - the queue is not mounted

2. アプライアンスによるの結合 された RAM 使用方法。  これは多くのと許可される着信接続/インジェクトを余りに見られるリスナーやメール フロー ポリシーのミスコンフィギュレーションによって多分、通常引き起こされます。 Cisco は最大着信接続のための listenerconfig を検討することを推奨します。 Cisco は 300 でこれを設定 されます推奨します。

どの位修理スクリプトは完了するために奪取 する必要がありますか。

workqueue を修理することは ESA の状態によって 10 秒から数時間に何メッセージがアクティブな workqueue を通して現行にプロセスかどこでも、奪取でき。 破損の時のフルキューが付いている下端 アプライアンスの workqueue 修理は数時間がかかる可能性があります。

repairqueue が動作できなければ起こりましたりまたはない完全何がか。

ある特定の状況で、（例えば、アプライアンスの過剰なキュー） repairqueuewill 完了ことできないため。 repairqueuedoes が 4 時間後に完了しない場合、キューは多分 unrepairable であり、唯一の依存は非表示 CLI コマンド resetqueue の実行によって新しいキューを構築することです。 高度問題に関しては、アクティブなサポート ケースをオープンし、Ciscoサポート支援を持つために CiscoSupport に連絡して下さい。

関連情報

- Cisco E メール セキュリティ アプライアンス エンドユーザ ガイド

- Cisco E メール セキュリティ アプライアンス コマンドレファレンス

- resetqueue コマンドの使用法

- 作業キューはどのような順序で処理されますか 作業キューのパイプラインとは何ですか。

- テクニカルサポートとドキュメント - Cisco Systems