Solucionar problemas de WorkQueue mediante el comando Repairqueue en ESA

Introducción

Este documento describe el uso del comando CLI oculto repairqueue en Cisco Email Security Appliance (ESA) y cómo validar la recuperación de la cola.

Problema

Motivos para ejecutar el comando repairqueue:

• Error al indicar que la cola de trabajo no está montada. Esto suele ser el resultado de la corrupción de la cola después de un ciclo de alimentación o reinicio incorrecto del dispositivo.
• Un defecto conocido puede requerir este comando como solución alternativa (como el ID de bug de Cisco CSCuw2284: la cola de correo electrónico se daña después de un bloqueo del servicio de procesamiento de correo o un apagado incorrecto).
• Errores de aplicación, como los que hacen referencia a gcq.py, o al subsistema de administración de colas.
• Detalle de estado o cola de trabajo > velocidad informe números negativos.

• Status (Estado) o Status Detail (Detalle de estado) informa de un valor de Oldest Message (Mensaje más antiguo) que excede el umbral del perfil de rebote configurado.

  • Umbral predeterminado: 259200 segundos (3 días).
  • Para verificar el umbral, ingrese bounceconfig > edit, luego seleccione el perfil Default. Localice la línea. Introduzca el número máximo de segundos que un mensaje puede permanecer en la cola antes de que se rechace por error.

Motivos para no ejecutar el comando repairqueue:

• El procesamiento lento de la cola de trabajo no es una razón válida para ejecutar una reparación de la cola. Los administradores a menudo confunden el procesamiento lento de la cola de trabajo con la corrupción de la cola. Una cola de trabajo lenta suele deberse a un procesamiento repetido del mismo mensaje o de varios mensajes, ya que un servicio está sobreutilizando los recursos del sistema. Estos escenarios de procesamiento repetido a menudo no se reparan simplemente ejecutando repairqueue. Se requiere una resolución de problemas adicional del servicio o servicios afectados.

Entorno

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• ESA, todo el hardware y los appliances virtuales que ejecuten AsyncOS 11.0.0-264 o posterior

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). En las redes activas, confirme el impacto potencial de cada comando antes de continuar.

Cisco recomienda conocer estos temas:

• Capacidad del sistema, supervisión del sistema, estado del sistema y procesamiento general de mensajes a través de la cola de trabajo de ESA.
• Administración general del AEE.

Nota: Consulte la guía del usuario ESA o la ayuda en línea de la GUI ESA para obtener más detalles.

Resolución

El comando CLI repairqueue no repara todos los problemas o daños en la cola de trabajo. La utilidad intenta realizar una reparación de la cola de trabajo según el mejor esfuerzo posible.

1. Ejecute status detail y confirme si la cola de trabajo muestra síntomas ya descritos en el problema, como valores negativos o un problema de montaje de la cola.
2. Ejecute workqueue y elija la opción Rate. Confirme si los tipos de interés declarados apoyan la condición que se ha activado.
3. Compare el valor de Mensaje más antiguo en estado o detalle de estado con el umbral del perfil de rebote configurado. Si el valor supera el umbral, continúe con el procedimiento de reparación.

Advertencia: La ejecución de repairqueue puede dar lugar a la pérdida de mensajes activos en la cola de trabajo.

4. Ejecute repairqueue. El primer proceso ejecuta solicitudes de permiso una vez para continuar y ejecutar la reparación:

   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
   ...
   <<<SNIP FOR BREVITY>>>
   ...
   done
   Repair succeeded
   Starting Hermes
   Hermes Started
   
   Log into the system and verify the status of the system.

   Nota: En un ESA virtual, ignore el resultado, "Esperando a que la cola se monte: No se pudo abrir el dispositivo en /dev/ipmi0 o /dev/ipmi/0 o /dev/ipmidev/0: No existe dicho archivo o directorio" documentado bajo el defecto conocido de ID de bug de Cisco CSCuz28415.

5. Una vez finalizado el proceso de reparación y reparada la cola de trabajo, el dispositivo conserva un antiguo punto de control de la cola de trabajo anterior. Para reanudar la escritura de un nuevo punto de control para el procesamiento de la cola de trabajo, ejecute de nuevo repairqueue e ingrese el comando para Limpiar:

   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. Ejecute el comando status detail desde la CLI, o elija Monitor > System Status en la GUI. Confirme que el estado del sistema es En línea.
7. Revise los registros de correo para confirmar el procesamiento del correo. Desde la CLI, ejecute el comando tail mail_logs.
8. Ejecute el comando workqueue y elija la opción Rate (velocidad predeterminada de 10 segundos). Confirme que los índices de entrada y salida son razonables para el flujo de correo actual. Si la cola de trabajo tiene un gran retraso, puede tardar en agotarse.

Causa

Entre las causas comunes de daños en la cola de trabajo se incluyen:

1. Reinicios inesperados o apagados inadecuados (por ejemplo, interrupciones del suministro eléctrico). Dependiendo de los procesos backend que se estén ejecutando en ese momento, la cola puede dañarse o no montarse después del reinicio. En este caso, la CLI puede informar de errores tales como:

   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. Uso excesivo de la memoria (RAM). Esto se asocia comúnmente con la configuración de la política de flujo de correo o receptor que permite demasiadas conexiones entrantes o inyecciones. Revise listenerconfig y confirme que el valor máximo de conexiones entrantes es apropiado para la implementación.

Preguntas frecuentes

¿Qué sucede si mi ESA no está ejecutando 11.0.0-264 o una versión más reciente?

Los usuarios que tienen dispositivos que ejecutan versiones antiguas de AsyncOS que no tienen la opción de comando repairqueue hidden CLI pueden abrir un caso de soporte para que un ingeniero de soporte técnico de Cisco ayude con el procedimiento. Debe abrirse un túnel de soporte y estar disponible para que el Soporte técnico de Cisco acceda al dispositivo y ejecute el comando repairqueue. Póngase en contacto con el soporte de Cisco para abrir un caso de soporte activo.

¿La corrupción de la cola de trabajo significa pérdida de correo?

En la mayoría de los casos, la corrupción no equivale a la pérdida de correo. La cola está dañada debido a metadatos relacionados con el procesamiento de mensajes que ya no están en el dispositivo. Se trata del mantenimiento de registros para el procesamiento entre la cola, los informes y el seguimiento de mensajes. La ejecución de repairqueue reconstruye los metadatos de ESA y limpia cualquier información errónea entre los servicios y el procesamiento.

¿Hay alguna repercusión en la corrupción de la cola de trabajo?

El ESA puede ejecutarse durante mucho tiempo en una cola dañada, y la mayoría de los mensajes todavía se procesan. Sin embargo, el dispositivo puede parecer lento, o algunos mensajes nunca pueden borrar, como lo indica el valor del mensaje más antiguo en el comando status (significativamente más antiguo que el umbral bounceconfig). Cuando AsyncOS se reinicia con una cola dañada, la cola puede fallar al montarse. La corrupción puede producirse antes y pasar desapercibida hasta que se reinicie el dispositivo, momento en el que la cola no se monta.

¿Cuánto tiempo puede tardar en completarse el script de reparación?

La reparación de la cola de trabajo puede tardar desde 10 segundos hasta varias horas, dependiendo del estado del ESA y de cuántos mensajes se estén procesando actualmente a través de una cola de trabajo activa. Una reparación de cola de trabajo en un dispositivo de gama inferior con colas completas en el momento de la corrupción podría tardar varias horas.

¿Qué sucede si la cola de reparación no se puede ejecutar o no se completa?

En determinadas situaciones (por ejemplo, una cola excesivamente llena en un dispositivo), la cola de reparación no se puede completar. si repairqueue no se completa después de 4 horas, lo más probable es que la cola no se pueda reparar y el único recurso es crear una nueva cola. Para estos problemas avanzados, comuníquese con Soporte técnico de Cisco para abrir un caso de soporte activo y obtener asistencia de Soporte técnico de Cisco.

Contenido relacionado

• Guías para usuarios finales de Cisco Email Security Appliance
• Referencias de comandos de Cisco Email Security Appliance
• ¿Cuál es el orden de procesamiento en la cola de trabajo? ¿Qué es la canalización de colas de trabajos?
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
2.0	02-Oct-2026	Recertificación
1.0	10-Aug-2017	Versión inicial