Uso del repairqueue del comando

Introducción

Este documento describe el uso del repairqueue del comando CLI ocultado y de las acciones que ocurre cuando esto el comando se publica del CLI de un dispositivo de seguridad del correo electrónico de Cisco (ESA).

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Capacidad del sistema, Control del sistema, Estados generales del sistema, y procesamiento total de los mensajes a través del workqueue ESA.
• La administración total ESA.

Nota: Consulte por favor el guía del usuario ESA o la Ayuda en Línea del ESA GUI para otros 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 dispositivos virtuales ejecutando AsyncOS 11.0.0-264 o más nuevo

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). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Problema

Razones para funcionar con el comando del repairqueue:

• Error que expone que el workqueue no está montado. Éste es generalmente un resultado del ciclo del poder de la corrupción de la cola o de la reinicialización poste-incorrecto del dispositivo.
• El defecto conocido requiere esto como workaround (tal como CSCuw22284 - la cola del email corrompe después de que los hermes causen un crash o apagado incorrecto).
• Incidentes de la aplicación, tales como ésos que se refieren a “gcq.py”, o el subsistema de la Administración de cola.
• El detalle o el workqueue > la tarifa del estatus están señalando los números negativos.
• Estatus o informes de la reunión el “más viejo mensaje” del estatus más viejo que su perfil de la despedida. El valor predeterminado para esto es 3 días. Usted puede verificar del bounceconfig > edita y elige el perfil predeterminado. Usted será el buscar “ingresa por favor el número máximo de segundos que un mensaje puede permanecer en la cola antes de ser” la línea difícilmente despedida, que por abandono es 259200 segundos, o 3 días. Esto excluye los dominios virtuales de la salida, the.<destination>.queue tal como the.cpq.queue, the.euq.queue, the.cpq.release.host.

Razones para no funcionar con el comando del repairqueue:

• El proceso lento del workqueue no es una razón válida para ejecutar una reparación de la cola. Los administradores confunden a menudo el workqueue lento que procesa como corrupción de la cola. Un workqueue lento debe generalmente relanzar el proceso de los mismos mensajes debidos mantener la sobre-utilización de los recursos del sistema. Éstas relanzadas procesando los escenarios no son a menudo las cosas que son reparadas simplemente ejecutando el repairqueue. Fomente el troubleshooting de los servicios que un mensaje “sería colgado” encendido durante el proceso sería requerido.

Uso del repairqueue del comando

Ejecutar el repairqueue del comando CLI puede no reparar todos los problemas o corrupciones del workqueue. Esta utilidad hace un mejor esfuerzo para reparar el workqueue.

Advertencia: Los administradores ESA deben tomar la nota, allí son la posibilidad de perder los mensajes activos de un workqueue.

Al ejecutar el repairqueue, el primer funcionamiento de proceso indicará para el permiso para proceder y para ejecutar una vez 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 el producto siguiente, el defecto conocido (CSCuz28415): “Esperando la cola para montar: No podía abrir el dispositivo en /dev/ipmi0 o /dev/ipmi/0 o /dev/ipmidev/0: Ningún tal archivo o directorio”

Una vez que se completa el proceso de reparación, el workqueue será reparado, no obstante el dispositivo todavía conservará un punto de verificación viejo del workqueue anterior. Para reanudar el escribir de un nuevo punto de verificación para el workqueue que procesa, ejecute el repairqueue otra vez, y publique el comando de limpiar:

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 completa el repairqueue, haga por favor cada uno del siguiente para validar el workqueue está detrás en línea y el dispositivo está procesando el correo:

1. Verifique el estado del sistema funcionando con el comando detail del estatus del CLI, o el monitor > el estado del sistema del GUI.  El dispositivo debe reflejar un estado del sistema de Online.  
2. Revise el correo abre una sesión el dispositivo para asegurar el correo que procesa como se esperaba.  Esto puede ser realizado del CLI funcionando con el comando de los mail_logs de la cola.
3. Funcione con el comando del workqueue del CLI, eligiendo la opción de la tarifa con la velocidad predeterminada de 10 segundos. Mientras el dispositivo esté procesando el correo adentro y/o el correo hacia fuera, la tarifa cada 10 segundos debe ser bastante igual para la relación de transformación del “in/out”. Los dispositivos que tienen un grande hasta que finalice el proceso del workqueue pueden tardar un cierto tiempo para vaciar el workqueue hacia fuera, y reanudan el proceso normal.

FAQ

¿Qué si mi ESA no está ejecutando 11.0.0-264 o más nuevo?

Los clientes que tienen dispositivos que funcionan con las versiones anteriores de AsyncOS que no tienen la opción ocultada repairqueue del comando CLI deben abrir un caso de soporte para tener una ayuda del ingeniero de soporte de Cisco.  Un túnel del soporte necesitará estar abierto y disponible para que el soporte de Cisco acceda el dispositivo y funcione con el proceso de la cola de la reparación.  Entre en contacto por favor el soporte de Cisco para abrir un caso de soporte activo.

¿El medio de la '' corrupción” del workqueue envía la pérdida?

En la mayoría de los casos, la corrupción no iguala la pérdida del correo. La cola es corrupto debido a los meta datos relacionados con el procesamiento de mensajes que están no más en el dispositivo. Esto es una contabilidad que procesa entre la cola e información, Seguimiento de mensajes, etc. que ejecuta el repairqueue reconstruirá los meta datos y la limpieza ESA misreporting entre los servicios y el proceso.

¿Hay repercusiones a la corrupción del workqueue?

El ESA puede poder ejecutarse durante mucho tiempo en una cola corrompida y la mayoría de los mensajes pueden procesar muy bien, pero el dispositivo puede aparecer tardo, o ciertos mensajes pueden nunca vaciar, según lo indicado por el “más viejo mensaje” del comando status --- perceptiblemente más viejo que el bounceconfig debe permitir. Cuando AsyncOS se recomienza realmente con una cola corrompida, la cola puede o no puede poder montar. La corrupción pudo haber ocurrido hace algún tiempo y aparece ser multa hasta que se recomience el dispositivo, momento en el cual que no puede montar la cola.

¿Qué causa la corrupción de la cola?

Dos la mayoría de las causas comunes de la “corrupción de la cola” son:

1. Reinicializaciones inesperadas del dispositivo. Las interrupciones del poder o el mantenimiento del botón del poder darán lugar a un apagado incorrecto y pueden corromper la cola, dependiendo de qué procesos backend hacían en ese entonces. El dispositivo puede recuperarse y la cola puede venir salvaguardia corrompida, o la cola puede no ser aumentable sobre la reinicialización. Si esto es verdad, los administradores ESA verán las alertas y/o “la daemon no montadas de la “cola” que no responden” al ejecutar el estatus del 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 del RAM del Hacia fuera-de-límite por el dispositivo.  Esto es causada muy probablemente por un misconfiguration de las directivas del flujo del módulo de escucha y/o de correo, visto generalmente con también muchos la conexión hacia adentro/las inyecciones permitidas. Cisco recomienda revisar su listenerconfig para las conexiones hacia adentro máximas. Cisco recomienda esto se fije en 300.

¿Cuánto tiempo debe el script de la reparación tomar para completar?

La reparación del workqueue puede tomar dondequiera a partir de 10 segundos a varias horas, dependiendo del estado del ESA y cuánto el mensaje está procesando actualmente a través de un workqueue activo. Una reparación del workqueue en un dispositivo más bajo con las colas completas a la hora de la corrupción podría tardar varias horas.

¿Qué sucede si el repairqueue no puede ejecutarse o hace no completo?

En ciertas situaciones, (e.g, cola sobre-FULL en un dispositivo) el repairqueuewill no poder completar. Si los repairqueuedoes no completan después de 4 horas, la cola es muy probablemente irreparable y el único recurso es construir una nueva cola ejecutando el resetqueue ocultado del comando CLI. Para los problemas avanzados, entre en contacto por favor CiscoSupport para abrir un caso de soporte activo y para tener una ayuda del soporte de Cisco.

Información Relacionada

• Guías del usuario final del dispositivo de seguridad del correo electrónico de Cisco
• Referencias de comandos del dispositivo de seguridad del correo electrónico de Cisco
• Uso del resetqueue del comando
• ¿Cuál es la orden del proceso en la cola de trabajo? ¿Cuál es la tubería de la cola de trabajo?
• Soporte Técnico y Documentación - Cisco Systems