在ESA上使用Repearqueue命令解决工作队列问题

简介

本文档介绍在思科邮件安全设备(ESA)上使用隐藏的CLI命令repairqueue以及如何验证队列恢复。

问题

运行repairqueue命令的原因：

• 指出工作队列未装入的错误。这通常是由于设备重新通电或重新启动不正确后发生队列损坏所致。
• 已知缺陷可能要求使用此命令作为解决方法（例如Cisco bug ID CSCuw2284 — 邮件处理服务崩溃或错误关闭后电子邮件队列损坏）。
• 应用故障，例如引用gcq.py或队列管理子系统的故障。
• 状态详细信息或工作队列>速率报告负数。

• Status或Status Detail报告超过已配置的退回配置文件阈值的最早消息值。

  • 默认阈值：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. 运行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上，忽略输出“Waiting for the queue to mount:无法打开位于/dev/ipmi0、/dev/ipmi/0或/dev/ipmidev/0的设备：已知缺陷Cisco bug 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命令。请与思科支持联系，以打开有效的支持案例。

工作队列损坏是否意味着邮件丢失？

在大多数情况下，腐败不等于邮件丢失。队列已损坏，原因是与设备上不再存在的邮件处理相关的元数据。这是用于队列、报告和邮件跟踪之间处理的记录。运行repairqueue会重建ESA元数据，并清除服务与处理之间的任何错误报告。

对工作队列损坏是否有影响？

ESA可以在损坏的队列上运行很长时间，并且大多数消息仍在处理中。但是，设备可能会显得很迟缓，或者某些消息永远无法清除，如status命令中的Oldest Message值（显着早于bounceconfig阈值）所指示。 当AsyncOS重新启动时队列已损坏，队列可能无法安装。损坏可能会更早发生，并且不会引起注意，直到设备重新启动，此时队列无法装载。

修复脚本需要多长时间才能完成？

修复工作队列可能需要10秒到几个小时不等，具体取决于ESA的状态以及当前通过活动工作队列处理的消息数量。在损坏时，在拥有完整队列的低端设备上修复工作队列可能需要几个小时。

如果修复队列无法运行或未完成，会发生什么情况？

在某些情况下（例如，设备上的队列过满），repairqueue无法完成。如果repaairqueue在4小时后未完成，则队列很可能不可修复，并且唯一的追索权是构建新队列。对于此类高级问题，请联系思科支持以打开有效的支持案例并请求思科支持帮助。

相关内容

• 思科邮件安全设备最终用户指南
• 思科邮件安全设备命令参考
• 工作队列中的处理顺序是什么？工作队列管线是什么？
• 技术支持和文档 - Cisco Systems

修订历史记录

版本	发布日期	备注
2.0	02-Oct-2026	重新认证
1.0	10-Aug-2017	初始版本