在ESA上使用Repairqueue命令排查工作隊列問題

簡介

本檔案介紹思科電子郵件安全裝置(ESA)上隱藏CLI命令repairequeue的使用方式以及如何驗證佇列復原。

問題

運行repairqueue命令的原因：

• 指出未裝入工作隊列的錯誤。這通常是由於裝置的電源重啟不正確或重新啟動後發生隊列損壞所致。
• 已知缺陷可要求此命令作為解決方法(例如Cisco bug ID CSCuw2284 — 郵件處理服務崩潰或不當關閉後電子郵件隊列損壞)。
• 應用程式故障，例如引用gcq.py或隊列管理子系統的故障。
• 狀態詳細資訊或工作隊列>速率報表負數。

• Status或Status Detail報告Oldest Message值超過配置的退回配置檔案閾值。

  • 預設閾值：259200秒（3天）。
  • 要檢查閾值，請輸入bounceconfig > edit，然後選擇Default配置檔案。找到該行，請輸入郵件在硬退回之前可以保留在隊列中的最大秒數。

不運行repairqueue命令的原因：

• 工作隊列處理緩慢不是運行隊列修復的有效原因。管理員通常將工作隊列處理緩慢與隊列損壞混淆。工作隊列緩慢的原因通常是重複處理同一條消息或多個消息，因為服務過度利用了系統資源。這些重複處理的情形通常無法通過運行repaairqueue來修復。需要對受影響的服務或服務進行進一步的故障排除。

環境

本文中的資訊係根據以下軟體和硬體版本：

• ESA，所有運行AsyncOS 11.0.0-264或更高版本的硬體和虛擬裝置

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。在活動網路中，請在繼續操作之前確認每個命令的潛在影響。

思科建議瞭解以下主題：

• 通過ESA工作隊列對消息進行系統容量、系統監控、系統運行狀況和整體處理。
• ESA的總體管理。

附註：有關詳細資訊，請參閱《ESA使用手冊》或《ESA GUI聯機幫助》。

解析

CLI命令repairqueue不會修復所有工作隊列問題或損壞。該實用程式將嘗試盡力修復工作隊列。

1. 運行status detail，並確認工作隊列是否顯示問題中已經描述的症狀，例如負值或隊列裝入問題。
2. 運行workqueue並選擇Rate選項。確認報告的速率是否支援觸發條件。
3. 將status或status detail中的Oldest Message值與配置的退回配置檔案閾值進行比較。如果值超過閾值，請繼續執行修復過程。

警告：運行repairqueue可能導致丟失工作隊列中的活動消息。

4. 運行repaairqueue。第一個進程會運行一次提示輸入許可權以繼續執行修復：

   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上，忽略輸出「正在等待隊列裝載：無法開啟位於/dev/ipmi0、/dev/ipmi/0或/dev/ipmidev/0的裝置：已知缺陷Cisco錯誤ID CSCuz28415下未記錄任何此類檔案或目錄」。

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。確認系統狀態為「Online（聯機）」。
7. 檢視郵件日誌以確認郵件處理。在CLI中運行tail mail_logs命令。
8. 運行workqueue命令並選擇Rate選項（預設值為10秒）。 確認當前郵件流的傳入和傳出速率是合理的。如果工作隊列有大量積壓工作，則可能需要一段時間才能排空。

原因

工作隊列損壞的常見原因包括：

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，並確認適用於部署的最大入站連線值。

常見問題

如果我的ESA沒有運行11.0.0-264或更高版本，該怎麼辦？

如果裝置運行的舊版AsyncOS沒有repairqueue hidden CLI命令選項，則使用者可以開啟支援案例，以便讓思科支援工程師協助該過程。需要開啟支援隧道，思科支援人員可以使用該隧道訪問裝置並運行repairqueue命令。聯絡思科支援以開啟有效的支援案例。

工作隊列損壞是否意味著郵件丟失？

在大多數情況下，腐敗並不等於郵件丟失。隊列已損壞，原因是與裝置上不再存在的郵件處理相關的後設資料。這是用於隊列、報告和郵件跟蹤之間處理的記錄保留。運行repaairqueue將重建ESA後設資料，並清除服務與處理之間的任何誤報告。

工作隊列損壞是否有影響？

ESA可以在損壞的隊列上運行很長時間，並且大多數消息仍在處理中。但是，裝置可能顯示緩慢，或者某些消息永遠無法清除，如status命令中的Oldest Message值(明顯早於bounceconfig閾值)所指示。 當AsyncOS重新啟動時隊列已損壞，隊列可能無法裝載。損壞可能較早發生，並且不會引起注意，直到裝置重新啟動，此時隊列無法裝載。

修復指令碼需要多長時間才能完成？

修復工作隊列可能需要10秒到幾個小時不等，具體取決於ESA的狀態以及當前通過活動工作隊列處理的消息數量。在損壞時具有完整隊列的低端裝置上修復工作隊列可能需要幾個小時。

如果修復隊列無法運行或不完成，會發生什麼情況？

在某些情況下（例如，裝置上的隊列過滿），repaairqueue無法完成。如果repaairqueue 4小時後未完成，則隊列極有可能無法修復，並且唯一的補救方法就是構建新隊列。對於此類高級問題，請聯絡思科支援以開啟有效的支援案例並獲得思科支援幫助。

相關內容

• Cisco Email Security Appliance最終使用手冊
• 思科郵件安全裝置命令參考
• 工作隊列中的處理順序是什麼？工作隊列管線是什麼？
• 技術支援與文件 - Cisco Systems

修訂記錄

修訂	發佈日期	意見
2.0	02-Oct-2026	重新認證
1.0	10-Aug-2017	初始版本