簡介
本文檔介紹隱藏CLI命令repairqueue 的用法，以及從Cisco郵件安全裝置(ESA)的CLI發出此命令時發生的操作。
必要條件
需求
思科建議您瞭解以下主題：
- 系統容量、系統監控、系統運行狀況，以及透過ESA工作隊列對消息的整體處理。
- 整個ESA管理。
註：有關詳細資訊，請參閱ESA使用手冊或ESA GUI的聯機幫助。
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- 運行AsyncOS 11.0.0-264或更新版本的ESA、所有硬體和虛擬裝置
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
問題
運行repairqueue命令的原因：
- 指出未裝載工作隊列的錯誤。這通常是由於裝置在不正確的電源重啟後隊列損壞或重新啟動所致。
- 已知缺陷需要將此作為解決方法(例如CSCuw22284 -在Hermes崩潰或不當關閉後，電子郵件隊列損壞)。
- 應用程式錯誤，例如參照「gcq.py」或佇列管理子系統的錯誤。
- 狀態明細或workqueue > rate正在報告負數。
- 狀態或狀態詳細資訊報告「最早郵件」早於退回配置檔案。此值的預設值為3天。您可以從bounceconfig > edit中進行驗證並選擇Default配置檔案。您將查詢「請輸入郵件在強制退回之前可保留在隊列中的最大秒數」行，預設值為259200秒或3天。這不包括虛擬傳遞網域、.<destination>.queue （例如.cpq.queue、.euq.queue、.cpq.release.host）。
不運行repairqueue命令的原因：
- 工作隊列處理緩慢不是運行隊列修復的有效原因。管理員經常將緩慢的工作隊列處理混淆為隊列損壞。工作隊列緩慢通常是由於服務過度利用系統資源導致重複處理同一條消息。通常，這些重複處理場景不是透過運行repairqueue就能修復的。需要進一步疑難排解在處理期間訊息將「擱置」的服務。
命令repairqueue的使用
運行CLI命令repairqueue可能無法修復所有工作隊列問題或損壞。此公用程式會盡力修復工作佇列。
警告： ESA管理員應該注意，可能會丟失來自工作隊列的活動消息。
運行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)：「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」
修復過程完成後，將修復工作隊列，但裝置仍會保留上一個工作隊列的舊檢查點。要繼續寫入工作隊列處理的新檢查點，請再次運行repairqueue，然後發出命令Clean：
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完成，請執行以下操作以驗證工作隊列是否恢復線上以及裝置是否正在處理郵件：
- 透過從CLI運行status detail命令或從GUI運行Monitor > System Status來驗證系統狀態。裝置應將系統狀態反映為Online。
- 檢視裝置上的郵件日誌，以確保郵件處理符合預期。 可從CLI運行tail mail_logs命令完成此操作。
- 從CLI運行workqueue命令，選擇Rate選項且預設速率為10秒。只要裝置正在處理傳入和/或傳出的郵件，則每10秒的速率應與「傳入/傳出」比率相當相等。具有大型擱置處理工作佇列的裝置可能需要一些時間來清空工作佇列，並恢復正常處理。
常見問題
如果我的ESA未運行11.0.0-264或更高版本，該怎麼辦？
如果客戶所運行的裝置運行AsyncOS的較早版本沒有repairqueue hidden CLI命令選項，則應提交支援請求，以獲得Cisco支援工程師幫助。 需要打開支援隧道，思科支援人員才能訪問該裝置並運行修復隊列流程。 請與Cisco支援聯絡以建立一個活躍的支援案例。
工作隊列「損壞」是否意味著郵件丟失？
在大多數情況下，損壞並不等於郵件丟失。佇列已損毀，因為與已不在裝置上的訊息處理相關的中繼資料。這是佇列與報告、訊息追蹤等之間的簿記處理。運行repairqueue將重建ESA後設資料，並清除服務與處理之間的任何誤報告。
工作隊列損壞是否有任何影響？
ESA可以在已損壞的隊列上運行很長時間，大多數消息可能會處理良好，但裝置可能顯示緩慢，或者某些消息可能永遠不會清除，如status命令中的「Oldest Message」所指示—明顯比bounceconfig所允許的版本舊。當AsyncOS實際上重新啟動，且隊列已損壞時，隊列可能能夠裝載，也可能無法裝載。損壞可能發生在某個時間之前，並且在重新啟動裝置之前似乎正常，此時裝置無法裝入隊列。
什麼原因導致隊列損壞？
「隊列損壞」的兩個最常見原因是：
- 裝置意外重新啟動。電源中斷或按住電源按鈕會導致不正確的關機，並可能損壞佇列，具體取決於當時的後端處理序正在執行的動作。裝置可能會恢復，並且隊列可能會恢復為已損壞，或者該隊列在重新啟動後可能無法裝入。如果這是真的，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
- 裝置超出界限的RAM使用量。 這很可能是因為監聽器和/或郵件流策略的配置錯誤，通常在允許過多的入站連線/注入時出現。Cisco建議檢查您的listenerconfig以獲取最大入站連線數。思科建議將此值設定為300。
完成修復程式檔需要多長時間？
修復工作隊列可能需要從10秒到幾個小時不等，具體取決於ESA的狀態以及當前透過活動工作隊列處理的消息數量。在下端裝置上修復在損壞時具有完整隊列的工作隊列可能需要幾個小時。
如果修復隊列無法運行或未完成，會發生什麼情況？
在某些情況下（例如，裝置上的隊列過滿），repairqueue將無法完成。如果repairqueue在4小時後未完成，則隊列極有可能無法修復，唯一的辦法是透過運行隱藏的CLI命令resetqueue構建新隊列。對於高級問題，請與思科支援聯絡以建立一個有效的支援案例並尋求思科支援幫助。
相關資訊
意見