Utilisation de la commande repairqueue

Introduction

Ce document décrit l'utilisation de la commande cachée CLI repairqueue et les actions qui se produisent quand cette commande est émise à partir de la CLI d'un appareil de sécurité de la messagerie Cisco (ESA).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Capacité du système, surveillance du système, état du système et traitement global des messages via la file d'attente de travail ESA.
• Administration générale de l'ESA.

Remarque : veuillez consulter le Guide de l'utilisateur ESA ou l'aide en ligne de l'interface utilisateur graphique ESA pour plus de 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, tous les appareils matériels et virtuels exécutant AsyncOS 11.0.0-264 ou version ultérieure

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problème

Raisons d'exécuter la commande repairqueue :

• Erreur indiquant que la file d'attente n'est pas montée. Cela est généralement dû à une corruption de la file d'attente après un redémarrage ou une mise hors tension incorrecte de l'appliance.
• Un défaut connu nécessite ceci comme une solution de contournement (comme CSCuw2284 - File d'attente des e-mails corrompue après une panne de Hermes ou un arrêt incorrect).
• Défauts d'application, tels que ceux faisant référence à « gcq.py », ou le sous-système de gestion des files d'attente.
• Détails d'état ou file d'attente de travail > taux signalent des nombres négatifs.
• Le rapport Status ou Status Detail indique que le message le plus ancien est plus ancien que votre profil de renvoi. La valeur par défaut est de 3 jours. Vous pouvez vérifier à partir de bounceconfig > edit et choisir le profil par défaut. Vous recherchez la ligne « Veuillez saisir le nombre maximal de secondes pendant lesquelles un message peut rester dans la file d'attente avant d'être renvoyé », qui est par défaut de 259200 secondes, ou 3 jours. Cela exclut les domaines de remise virtuels, la file d'attente.<destination>.queue, comme la file d'attente.cpq.queue, la file d'attente.euq.queue, la file d'attente.cpq.release.host.

Raisons de NE PAS exécuter la commande repairqueue :

• Le traitement lent de la file d'attente n'est pas une raison valide pour exécuter une réparation de file d'attente. Les administrateurs confondent souvent le traitement lent des files d'attente et la corruption des files. Une file d'attente de travail lente est généralement due au traitement répété du ou des mêmes messages en raison de la surutilisation des ressources système par le service. Souvent, ces scénarios de traitement répétés ne sont pas des choses qui sont réparées par simplement exécuter repairqueue. Un dépannage plus approfondi du ou des services sur lesquels un message serait « accroché » pendant le traitement serait nécessaire.

Utilisation de la commande repairqueue

L'exécution de la commande CLI repairqueue peut ne pas réparer tous les problèmes ou altérations de file d'attente de travail. Cet utilitaire fait de son mieux pour réparer la file d'attente de travail.

Avertissement : les administrateurs ESA doivent prendre note qu'il existe un risque de perte des messages actifs d'une file d'attente de travail.

Lors de l'exécution de repairqueue, le premier processus exécuté demandera l'autorisation une fois pour continuer 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 le résultat suivant, anomalie connue (CSCuz28415) : "Attente du montage de la file d'attente : impossible d'ouvrir le périphérique à /dev/ipmi0 ou /dev/ipmi/0 ou /dev/ipmidev/0 : aucun fichier ou répertoire de ce type"

Une fois le processus de réparation terminé, la file d'attente de travail est réparée, mais l'appliance conserve un ancien point de contrôle de la file d'attente de travail précédente. Afin de reprendre l'écriture d'un nouveau point de contrôle pour le traitement de la file d'attente de travail, exécutez de nouveau la file d'attente de réparation, et émettez la commande à 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

Vérifier

Une fois la file d'attente de réparation terminée, effectuez chacune des opérations suivantes afin de valider que la file d'attente de travail est de nouveau en ligne et que l'appliance traite le courrier :

1. Vérifiez l'état du système en exécutant la commande status detail à partir de l'interface de ligne de commande ou Monitor > System Status à partir de l'interface utilisateur graphique. L'appliance doit refléter l'état du système Online.  
2. Vérifiez les journaux de messagerie sur l'appliance pour vous assurer que le traitement des messages est conforme aux attentes.  Pour ce faire, exécutez la commande tail mail_logs à partir de l'interface de ligne de commande.
3. Exécutez la commande workqueue à partir de l'interface de ligne de commande, en choisissant l'option Rate avec un débit par défaut de 10 secondes. Tant que la solution matérielle-logicielle traite les messages entrants et/ou sortants, le taux toutes les 10 secondes doit être à peu près égal pour le rapport « Entrants/Sortants ». Les appareils qui ont une file d'attente de traitement importante peuvent mettre un certain temps à vider la file d'attente et à reprendre le traitement normal.

Forum aux questions

Que faire si mon ESA n'exécute pas la version 11.0.0-264 ou ultérieure ?

Les clients qui ont des appareils exécutant d'anciennes versions d'AsyncOS qui n'ont pas l'option de commande repairqueue hidden CLI doivent ouvrir un dossier d'assistance afin d'avoir un ingénieur d'assistance Cisco d'aide.  Un tunnel d'assistance doit être ouvert et disponible pour que l'assistance Cisco puisse accéder à l'appliance et exécuter le processus de file d'attente de réparation.  Veuillez contacter l'assistance Cisco pour ouvrir un dossier d'assistance actif.

La file d'attente de travail « corrompue » signifie-t-elle une perte de messages ?

Dans la plupart des cas, la corruption n'est pas synonyme de perte de messages. La file d'attente est endommagée en raison de métadonnées liées au traitement des messages qui ne figurent plus sur l'appliance. Il s'agit d'un traitement comptable entre la file d'attente et les rapports, le suivi des messages, etc. L'exécution de la file d'attente de réparation reconstruira les métadonnées ESA et éliminera tout rapport erroné entre les services et le traitement.

La corruption des files d'attente a-t-elle des répercussions ?

L'ESA peut être capable de fonctionner pendant une longue période sur une file d'attente corrompue et la plupart des messages peuvent être traités correctement, mais l'appliance peut sembler lente, ou certains messages peuvent ne jamais disparaître, comme indiqué par le « Message le plus ancien » dans la commande d'état — significativement plus ancien que ce que la configuration de rebondissement devrait permettre. Lorsque AsyncOS est redémarré avec une file d'attente endommagée, la file d'attente peut être montée ou non. La corruption s'est peut-être produite il y a quelque temps et semble fonctionner correctement jusqu'au redémarrage de l'appliance, auquel cas il ne peut pas monter la file d'attente.

Quelles causes corrompent la file d'attente ?

Les deux causes les plus courantes de « corruption de file d'attente » sont :

1. Redémarrages inattendus de l'appliance. Les coupures d'alimentation ou le fait de maintenir le bouton d'alimentation enfoncé entraînent un arrêt incorrect et peuvent endommager la file d'attente, selon ce que les processus principaux faisaient à ce moment-là. Il se peut que l'appliance récupère et que la file d'attente revienne endommagée, ou que la file d'attente ne puisse pas être montée au redémarrage. Si cela est vrai, les administrateurs ESA verront des alertes « file d'attente non montée » et/ou « démon ne répondant pas » lors de l'exécution de l'état à partir de l'interface de ligne de commande.
   
   

   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 la mémoire vive (RAM) sortante par l'appliance.  Cela est probablement dû à une mauvaise configuration de l'écouteur et/ou des stratégies de flux de messagerie, généralement en raison d'un trop grand nombre de connexions/injections entrantes autorisées. Cisco recommande de vérifier votre listenerconfig pour le nombre maximal de connexions entrantes. Cisco recommande de définir cette valeur sur 300.

Combien de temps le script de réparation doit-il durer ?

La réparation de la file d'attente peut prendre de 10 secondes à plusieurs heures, selon l'état de l'ESA et le nombre de messages en cours de traitement dans une file d'attente active. La réparation d'une file d'attente de travail sur une appliance de bas de gamme avec des files d'attente pleines au moment de la corruption peut prendre plusieurs heures.

Que se passe-t-il si la file d'attente de réparation ne peut pas fonctionner ou ne se termine pas ?

Dans certaines situations (par exemple, file d'attente saturée sur un appareil), la file d'attente de réparation ne pourra pas être terminée. Si la file d'attente de réparation ne se termine pas 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 la commande masquée CLI resetqueue. Pour les problèmes avancés, veuillez contacter l'assistance Cisco pour ouvrir un dossier d'assistance actif et demander une assistance Cisco.

Informations connexes

• Guides d'utilisation de l'appliance de sécurisation de la messagerie Cisco
• Références des commandes de l'appliance de sécurisation de messagerie Cisco
• Utilisation de la commande resetqueue
• Quel est l'ordre de traitement dans la file d'attente de travail ? Quel est le pipeline de file d'attente de travail ?
• Assistance et documentation techniques - Cisco Systems