Utilisation du repairqueue de commande

Introduction

Ce document décrit l'utilisation du repairqueue masqué de commande CLI et des actions qui se produit quand ceci la commande est émis du CLI d'une appliance de sécurité du courrier électronique de Cisco (ESA).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Capacité système, contrôle du système, états du système, et traitement global des messages par le workqueue ESA.
• Gestion globale ESA.

Remarque: Veuillez consulter le guide utilisateur ESA ou l'aide en ligne du GUI ESA pour d'autres détails.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• ESA, tout le matériel et appliances virtuelles exécutant AsyncOS 11.0.0-264 ou plus nouveau

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème

Raisons d'exécuter la commande de repairqueue :

• Erreur déclarant que le workqueue n'est pas monté. C'est habituellement un résultat d'arrêt et redémarrage de corruption de file d'attente ou de réinitialisation POST-inexact de l'appliance.
• Le défaut connu exige ceci comme contournement (tel que CSCuw22284 - la file d'attente d'email corrompt après que les hermes tombent en panne ou arrêt inexact).
• Défauts d'application, comme ceux mettant en référence « gcq.py », ou le sous-système de Gestion de file d'attente.
• Le détail ou le workqueue > le débit d'état signalent des numéros négatifs.
• États « le message le plus ancien » d'état ou de détail d'état plus ancien que votre profil de rebond. La valeur par défaut pour ceci est de 3 jours. Vous pouvez vérifier du bounceconfig > éditez et choisissez le profil par défaut. Vous serez recherche « écrivez s'il vous plaît le nombre maximal de secondes où un message peut rester dans la file d'attente avant d'être » la ligne dur rebondie, qui par défaut est de 259200 secondes, ou de 3 jours. Ceci exclut les domaines virtuels de la livraison, the.<destination>.queue tel que the.cpq.queue, the.euq.queue, the.cpq.release.host.

Raisons de ne pas exécuter la commande de repairqueue :

• Le traitement lent de workqueue n'est pas un motif valable d'exécuter une réparation de file d'attente. Les administrateurs confondent souvent le workqueue lent traitant comme corruption de file d'attente. Un workqueue lent doit habituellement répéter le traitement des mêmes messages devant entretenir la sur-utilisation des ressources système. Souvent ce répétées traitant des scénarios ne sont pas des choses qui sont réparées en exécutant simplement le repairqueue. Davantage de dépannage des services qu'un message « serait arrêté » en fonction pendant le traitement serait exigé.

Utilisation du repairqueue de commande

Exécuter le repairqueue de commande CLI peut ne pas réparer toutes les questions ou corruptions de workqueue. Cet utilitaire fait un meilleur effort pour réparer le workqueue.

Avertissement : Les administrateurs ESA devraient prendre la note, là est la possibilité de perdre les messages actifs d'un workqueue.

Quand exécutant le repairqueue, le premier passage de processus incitera pour l'autorisation une fois de poursuivre et exécuter la réparation :

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.

Remarque: Sur un ESA virtuel, ignorez la sortie suivante, le défaut connu (CSCuz28415) : « Attendant la file d'attente pour monter : N'a pas pu ouvrir le périphérique chez /dev/ipmi0 ou /dev/ipmi/0 ou /dev/ipmidev/0 : Aucun un tel fichier ou répertoire »

Une fois le processus de réparation est terminé, le workqueue sera réparé, toutefois l'appliance retiendra toujours un vieux point de reprise du workqueue précédent. Afin de reprendre écrire un nouveau point de reprise pour le workqueue traitant, exécutez le repairqueue de nouveau, et émettez la commande de nettoyer :

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

Vérifiez

Une fois que le repairqueue est terminé, faites s'il vous plaît chacune du suivant afin de valider le workqueue est de retour en ligne et l'appliance traite la messagerie :

1. Vérifiez l'état du système en exécutant la commande de détail d'état du CLI, ou le moniteur > l'état du système du GUI.  L'appliance devrait refléter un état du système d'en ligne.  
2. Passez en revue la messagerie ouvre une session l'appliance pour assurer la messagerie traitant comme prévue.  Ceci peut faire du CLI en exécutant la commande de mail_logs de queue.
3. Exécutez la commande de workqueue du CLI, choisissant l'option de débit avec du débit par défaut de 10 secondes. Tant que l'appliance traite la messagerie dedans et/ou la messagerie, le débit chaque 10 secondes devrait être assez égal pour le rapport de « entrée/sortie ». Les appliances qui ont un grand en attendant le traitement du workqueue peuvent prendre un certain temps de vider le workqueue, et reprennent le traitement normal.

FORUM AUX QUESTIONS

Que si mon ESA n'exécute pas 11.0.0-264 ou plus nouveau ?

Les clients qui ont des appliances exécutant des versions plus anciennes d'AsyncOS qui n'ont pas l'option de commande CLI masquée par repairqueue devraient ouvrir une valise de support afin d'avoir une aide d'ingénieur d'assistance technique de Cisco.  Un tunnel de support devra être ouvert et disponible pour que le support de Cisco accède à l'appliance et pour exécute le processus de file d'attente de réparation.  Veuillez entrer en contact avec le support de Cisco pour ouvrir une valise active de support.

Le moyen de '' corruption » de workqueue envoie-il par mail la perte ?

Dans la plupart des cas, la corruption n'égale pas la perte de messagerie. La file d'attente est due corrompu aux méta-données liées au traitement de messages qui ne sont plus sur l'appliance. C'est une comptabilité traitant entre la file d'attente et l'enregistrement, message dépistant, etc. exécutant le repairqueue reconstruira les méta-données et le nettoyage ESA misreporting entre les services et le traitement.

Y a-t-il des répercussions à la corruption de workqueue ?

L'ESA peut pouvoir s'exécuter pendant longtemps sur une file d'attente corrompue et la plupart des messages peuvent traiter bien, mais l'appliance peut sembler lente, ou certains messages peuvent ne jamais effacer, comme indiqué par « le message le plus ancien » dans la commande d'état ------ sensiblement plus vieux que le bounceconfig devrait laisser. Quand AsyncOS est redémarré réellement avec une file d'attente corrompue, la file d'attente peut ou peut ne pas pouvoir monter. La corruption a pu s'être produite il y a quelque temps et semble être bon jusqu'à ce que l'appliance soit redémarrée, laquelle au point il ne peut pas monter la file d'attente.

Quelles causes alignent la corruption ?

Les deux la plupart des causes classiques de la « corruption de file d'attente » sont :

1. Réinitialisations inattendues de l'appliance. Les interruptions d'alimentation ou le maintien du bouton d'alimentation auront comme conséquence un arrêt inexact et peuvent corrompre la file d'attente, selon quels processus principaux faisaient alors. L'appliance peut récupérer et la file d'attente peut se réactiver corrompu, ou la file d'attente peut ne pas être montable sur la réinitialisation. Si c'est vrai, les administrateurs ESA verront les alertes non montées et/ou « le démon de « file d'attente » ne répondant pas » quand exécutant l'état du 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. utilisation de RAM de -de-limite par l'appliance.  Ceci est très probablement provoqué par une mauvaise configuration de l'auditeur et/ou des stratégies de flux de courrier, habituellement vue avec trop des beaucoup la connexion entrante/injections permises. Cisco recommande de passer en revue votre listenerconfig pour les connexions entrantes maximum. Cisco recommande ceci soit placé à 300.

Combien de temps le script de réparation devrait-il prendre pour se terminer ?

Réparer le workqueue peut prendre n'importe où de 10 secondes à plusieurs heures, selon l'état de l'ESA et combien le message traitent actuellement par un workqueue actif. Une réparation de workqueue sur une appliance plus bas de gamme avec des files d'attente pleine au moment de la corruption pourrait prendre plusieurs heures.

Ce que se produit si le repairqueue ne peut pas fonctionner ou ne se termine pas ?

Dans certaines situations, (par exemple, file d'attente trop pleine sur une appliance) le repairqueuewill ne pas pouvoir se terminer. Si les repairqueuedoes pas se terminent après 4 heures, la file d'attente est très probablement irréparable et le seul recours est de construire une nouvelle file d'attente en exécutant le resetqueue masqué de commande CLI. Pour les questions avancées, entrez en contact avec s'il vous plaît CiscoSupport pour ouvrir une valise active de support et avoir Cisco prenez en charge l'aide.

Informations connexes

• Guides d'utilisateur d'appareils de sécurité du courrier électronique de Cisco
• Références de commandes d'appareils de sécurité du courrier électronique de Cisco
• Utilisation du resetqueue de commande
• Quelle est la commande du traitement dans la file d'attente de travail ? Quel est le pipeline de file d'attente de travail ?
• Support et documentation techniques - Cisco Systems