Uso del comando repairqueue

Introducción

Este documento describe el uso del comando CLI oculto repairqueue y las acciones que se producen cuando este comando se ejecuta desde la CLI de un dispositivo de seguridad de correo electrónico (ESA) de Cisco.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre 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 de ESA o la ayuda en línea de la GUI de ESA para obtener más detalles.

Componentes Utilizados

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). If your network is live, make sure that you understand the potential impact of any command.

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.
• Defecto conocido requiere esto como una solución alternativa (como CSCuw2284 - La cola de correo electrónico se corrompe después del bloqueo de hermes o cierre inadecuado).
• Errores de la aplicación, como los que hacen referencia a "gcq.py" o al subsistema de administración de colas.
• Los detalles de estado o la cola de trabajo > velocidad informan de números negativos.
• Status o Status Detail informa de que el mensaje es "Oldest Message" más antiguo que su perfil de rebote. El valor predeterminado es 3 días. Puede verificar desde bounceconfig > edit y elegir el perfil predeterminado. Buscará la línea "Introduzca el número máximo de segundos que un mensaje puede permanecer en la cola antes de ser rechazado de forma segura", que de forma predeterminada es de 259200 segundos o 3 días. Esto excluye los dominios de entrega virtuales, la cola.<destination>.queue como, por ejemplo, the.cpq.queue, the.euq.queue, the.cpq.release.host.

Razones 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 suelen confundir el procesamiento lento de la cola de trabajo con la corrupción de la cola. Una cola de trabajo lenta se debe normalmente al procesamiento repetido de los mismos mensajes debido a la sobreutilización del servicio de los recursos del sistema. A menudo, estos escenarios de procesamiento repetido no son cosas que se reparan simplemente ejecutando repairqueue. Se requeriría una resolución de problemas adicional de los servicios en los que se "colgaría" un mensaje durante el procesamiento.

Uso del comando repairqueue

La ejecución del comando CLI repairqueue puede no reparar todos los problemas o daños de la cola de trabajo. Esta utilidad hace un mejor esfuerzo para reparar la cola de trabajo.

Advertencia: Los administradores de ESA deben tener en cuenta que existe la posibilidad de perder mensajes activos de una cola de trabajo.

Al ejecutar repairqueue, la primera ejecución del proceso solicitará permiso una vez para continuar y ejecutar la reparación:

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.

Nota: En un ESA virtual, ignore la siguiente salida, defecto conocido (CSCuz28415): "Esperando a que se monte la cola: No se pudo abrir el dispositivo en /dev/ipmi0 o /dev/ipmi/0 o /dev/ipmidev/0: No existe tal archivo o directorio"

Una vez finalizado el proceso de reparación, la cola de trabajo se reparará; sin embargo, el dispositivo conservará un punto de control antiguo 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 la cola de reparación nuevamente y ejecute el comando 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

Verificación

Una vez que se haya completado la cola de reparación, realice cada una de las siguientes acciones para validar que la cola de trabajo vuelve a estar en línea y que el dispositivo está procesando correo:

1. Verifique el estado del sistema ejecutando el comando status detail desde la CLI, o Monitor > System Status desde la GUI. El dispositivo debe reflejar un estado del sistema de Online.  
2. Revise los registros de correo en el dispositivo para garantizar que el procesamiento de correo se realiza según lo previsto.  Esto se puede lograr desde la CLI mediante la ejecución del comando tail mail_logs.
3. Ejecute el comando workqueue desde la CLI, eligiendo la opción Rate con una velocidad predeterminada de 10 segundos. Mientras el dispositivo esté procesando correo entrante y/o saliente, la velocidad cada 10 segundos debe ser bastante igual para la relación "Entrada/Salida". Los dispositivos que tienen una cola de trabajo de procesamiento pendiente grande pueden tardar algún tiempo en vaciar la cola de trabajo y reanudar el procesamiento normal.

Preguntas frecuentes

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

Los clientes que tienen dispositivos que ejecutan versiones antiguas de AsyncOS y que no tienen la opción de comando repairqueue hidden CLI deben abrir un caso de soporte para contar con la asistencia de un ingeniero de soporte de Cisco.  Será necesario abrir un túnel de asistencia y disponer de él para que el servicio de asistencia de Cisco pueda acceder al dispositivo y ejecutar el proceso de cola de reparación.  Póngase en contacto con el servicio de asistencia de Cisco para abrir un caso de asistencia 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 de un proceso de contabilidad entre la cola y la generación de informes, el seguimiento de mensajes, etc. La ejecución de la cola de reparación reconstruirá los metadatos de ESA y limpiará cualquier error de generación de informes 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 pueden procesarse correctamente, pero el dispositivo puede parecer lento, o ciertos mensajes pueden no borrarse nunca, como se indica en el "Mensaje más antiguo" del comando status — significativamente más antiguo de lo que el comando bounceconfig debería permitir. Cuando AsyncOS se reinicia realmente con una cola dañada, la cola puede o no ser capaz de montarse. La corrupción puede haber ocurrido hace algún tiempo y parece estar bien hasta que se reinicia el dispositivo, momento en el cual no puede montar la cola.

¿Qué causa la corrupción de colas?

Las dos causas más comunes de 'corrupción de cola' son:

1. Reinicios inesperados del dispositivo. Las interrupciones de alimentación o el mantenimiento del botón de alimentación dará lugar a un apagado incorrecto y puede dañar la cola, dependiendo de lo que los procesos backend estaban haciendo en ese momento. Es posible que el dispositivo se recupere y que la cola vuelva a estar dañada o que la cola no se pueda montar al reiniciar. Si esto es cierto, los administradores ESA verán alertas de "cola no montada" y/o "daemon no respondiendo" cuando se ejecute el estado desde la 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

2. Uso de RAM saliente por el dispositivo.  Esto se debe probablemente a una configuración incorrecta del receptor o de las políticas de flujo de correo, que se suele ver con demasiadas conexiones entrantes/inyecciones permitidas. Cisco recomienda revisar la configuración del listenerconfig para obtener el máximo de conexiones entrantes. Cisco recomienda que se establezca en 300.

¿Cuánto tiempo se tarda en completar 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 (p. ej., cola excesivamente llena en un dispositivo), la cola de reparación no podrá completarse. Si la cola de reparación 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 ejecutando el comando oculto CLI resetqueue. Para problemas avanzados, póngase en contacto con el Soporte de Cisco para abrir un caso de soporte activo y obtener asistencia del Soporte de Cisco.

Información Relacionada

• Guías para usuarios finales de Cisco Email Security Appliance
• Referencias de comandos de Cisco Email Security Appliance
• Uso del comando resetqueue
• ¿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