简介
本文档介绍隐藏CLI命令repairqueue的用法，以及从思科邮件安全设备(ESA)的CLI发出此命令时执行的操作。
先决条件
要求
Cisco 建议您了解以下主题：
- 通过ESA工作队列处理消息的系统容量、系统监控、系统运行状况和整体处理情况。
- ESA总体管理。
注意：请参阅ESA用户指南或ESA GUI的在线帮助，了解更多详细信息。
使用的组件
本文档中的信息基于以下软件和硬件版本：
- ESA，运行AsyncOS 11.0.0-264或更新版本的所有硬件和虚拟设备
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。
问题
运行repairqueue命令的原因：
- 指出未装入工作队列的错误。这通常是因设备重新通电不正确或重新启动后队列损坏所致。
- 已知缺陷需要将此作为解决方法(例如CSCuw22284 - Email queue corrupts after hermes crash or uncorrect shutdown)。
- 应用程序故障，例如引用“gcq.py”或队列管理子系统的故障。
- 状态详细信息或workqueue > rate正在报告负数。
- 状态或状态详细信息报告早于退回配置文件的“最早邮件”。此值的默认值为3天。您可以从bounceconfig > edit中进行验证，然后选择Default配置文件。您将查找“请输入邮件在硬退回之前可以保留在队列中的最大秒数”(Please enter the maximum number of seconds an message may be stay in the queue before be hard bounced)行，默认值为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运行statusdetail命令或从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实际重新启动且队列已损坏时，队列可能能够装入，也可能无法装入。损坏可能发生在某个时间之前，并且在重新启动设备之前似乎正常，此时无法装入队列。
什么原因导致队列损坏？
“队列损坏”的两个最常见原因是：
- 意外重新启动设备。电源中断或按住电源按钮会导致不正确的关闭并可能损坏队列，具体取决于当时后端进程执行的操作。设备可能会恢复，并且队列可能会重新损坏，或者队列在重新启动后无法装入。如果为true，则ESA管理员在从CLI运行status时将看到“queue not mounted”警报和/或“daemon not responding”。
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。 这很可能是由于侦听程序和/或邮件流策略配置错误(通常在允许的入站连接/注入过多时出现)所致。思科建议查看listenerconfig以获取最大入站连接数。Cisco建议将此值设置为300。
修复脚本需要多长时间才能完成？
修复工作队列可能需要10秒到几个小时，具体取决于ESA的状态以及当前通过活动工作队列处理的消息数量。在损坏时，在包含完整队列的低端设备上修复工作队列可能需要几个小时。
如果修复队列无法运行或未完成，会发生什么情况？
在某些情况下（例如，设备上的队列过满）repairqueue将无法完成。如果repairqueue在4小时后未完成，则该队列极有可能无法修复，唯一的解决方法是通过运行隐藏的CLI命令resetqueue来构建新队列。对于高级问题，请与思科支持联系以提交有效的支持案例并寻求思科支持帮助。
相关信息
反馈