Fehlerbehebung bei Arbeitswarteschlangen-Problemen mit dem Reparaturwarteschlangen-Befehl auf der ESA

Einleitung

In diesem Dokument wird die Verwendung der ausgeblendeten CLI-Befehl-Reparaturwarteschlange auf der Cisco Email Security Appliance (ESA) und die Validierung der Warteschlangenwiederherstellung beschrieben.

Problem

Gründe für die Ausführung des Befehls repairqueue:

• Fehler beim Angeben, dass die Arbeitswarteschlange nicht bereitgestellt ist. Dies ist in der Regel das Ergebnis einer fehlerhaften Warteschlangenkonfiguration nach einem unsachgemäßen Ein-/Ausschalten oder Neustart der Appliance.
• Ein bekannter Fehler kann diesen Befehl als Problemumgehung erfordern (z. B. Cisco Bug-ID CSCuw2284 - Die E-Mail-Warteschlange ist nach einem Absturz des E-Mail-Verarbeitungsdiensts oder einem nicht ordnungsgemäßen Herunterfahren beschädigt).
• Anwendungsfehler, z. B. die gcq.py oder das Warteschlangen-Management-Subsystem.
• Statusdetail oder Arbeitswarteschlange > Rate melden negative Zahlen.

• Status- oder Statusdetail-Meldungen melden einen Wert für die älteste Nachricht, der den konfigurierten Schwellenwert für Bounce-Profile überschreitet.

  • Standardschwellenwert: 259200 Sekunden (3 Tage).
  • Um den Schwellenwert zu überprüfen, geben Sie bounceconfig > edit ein, und wählen Sie dann das Standard-Profil aus. Suchen Sie die Leitung. Geben Sie die maximale Dauer in Sekunden ein, die eine Nachricht in der Warteschlange verbleiben darf, bevor sie per Hard-Bounce zurückgesendet wird.

Gründe, den Befehl repairqueue nicht auszuführen:

• Die langsame Verarbeitung der Arbeitswarteschlange ist kein gültiger Grund für die Durchführung einer Warteschlangenreparatur. Administratoren verwechseln die langsame Verarbeitung von Arbeitswarteschlangen häufig mit einer fehlerhaften Warteschlange. Eine langsame Arbeitswarteschlange resultiert in der Regel aus der wiederholten Verarbeitung derselben Nachricht oder mehrerer Nachrichten, da ein Dienst die Systemressourcen übermäßig beansprucht. Diese wiederholten Verarbeitungsszenarien werden häufig nicht durch einfaches Ausführen der Reparaturwarteschlange repariert. Eine weitere Fehlerbehebung für den oder die betroffenen Services ist erforderlich.

Umwelt

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• ESA, alle Hardware und virtuellen Appliances mit AsyncOS 11.0.0-264 oder höher

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Überprüfen Sie in Live-Netzwerken die möglichen Auswirkungen der einzelnen Befehle, bevor Sie fortfahren.

Cisco empfiehlt, sich mit folgenden Themen vertraut zu machen:

• Systemkapazität, Systemüberwachung, Systemstatus und Gesamtverarbeitung von Meldungen über die ESA-Arbeitswarteschlange.
• Gesamtverwaltung der ESA.

Anmerkung: Weitere Informationen finden Sie in der ESA-Bedienungsanleitung oder in der Online-Hilfe der ESA-Benutzeroberfläche.

Auflösung

Der CLI-Befehl repairqueue behebt nicht alle Probleme oder Beschädigungen in der Arbeitswarteschlange. Das Dienstprogramm versucht, eine bestmögliche Reparatur der Arbeitswarteschlange durchzuführen.

1. Führen Sie Statusdetails aus, und überprüfen Sie, ob die Arbeitswarteschlange Symptome wie negative Werte oder ein Problem beim Einhängen der Warteschlange zeigt, die bereits in Issue beschrieben wurden.
2. Führen Sie die Arbeitswarteschlange aus, und wählen Sie die Option Rate. Bestätigen Sie, ob die gemeldeten Raten die Auslösebedingung unterstützen.
3. Vergleichen Sie den Wert für die älteste Nachricht im Status- oder Statusdetail mit dem konfigurierten Bounce-Profilschwellenwert. Wenn der Wert den Schwellenwert überschreitet, fahren Sie mit dem Reparaturverfahren fort.

Warnung: Das Ausführen der Reparaturwarteschlange kann zum Verlust aktiver Nachrichten in der Arbeitswarteschlange führen.

4. Führen Sie eine Reparaturwarteschlange aus. Der erste Prozess startet eine Eingabeaufforderung, um einmalig die Berechtigung zum Fortfahren und Ausführen der Reparatur einzuholen:

   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.

   Anmerkung: Ignorieren Sie auf einer virtuellen ESA die Ausgabe "Waiting for the queue to mount: Gerät konnte nicht geöffnet werden unter /dev/ipmi0 oder /dev/ipmi/0 oder /dev/ipmidev/0: Keine solche Datei oder solches Verzeichnis" dokumentiert unter dem bekannten Defekt Cisco Bug-ID CSCuz28415.

5. Sobald der Reparaturprozess abgeschlossen und die Arbeitswarteschlange repariert ist, behält die Appliance einen alten Prüfpunkt der vorherigen Arbeitswarteschlange bei. Um mit dem Schreiben eines neuen Prüfpunkts für die Arbeitswarteschlangen-Verarbeitung fortzufahren, führen Sie die Reparaturwarteschlange erneut aus, und geben Sie den Befehl Bereinigen ein:

   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. Führen Sie den Befehl status detail in der CLI aus, oder wählen Sie Monitor > System Status in der GUI aus. Bestätigen Sie, dass der Systemstatus "Online" lautet.
7. Überprüfen Sie die E-Mail-Protokolle, um die E-Mail-Verarbeitung zu bestätigen. Führen Sie über die CLI den Befehl tail mail_logs aus.
8. Führen Sie den Befehl workqueue aus, und wählen Sie die Option Rate (Standardeinstellung: 10 Sekunden). Bestätigen Sie, dass die Ein- und Ausgänge für den aktuellen E-Mail-Fluss angemessen sind. Wenn die Arbeitswarteschlange einen großen Rückstand aufweist, kann es einige Zeit dauern, bis sie wieder leer ist.

Ursache

Häufige Ursachen für die Beschädigung von Arbeitswarteschlangen sind:

1. Unerwartete Neustarts oder nicht ordnungsgemäße Abschaltungen (z. B. Stromausfälle). Je nachdem, welche Backend-Prozesse gerade ausgeführt werden, kann die Warteschlange nach dem Neustart beschädigt werden oder nicht bereitgestellt werden. In diesem Fall kann die CLI Fehler wie die folgenden melden:

   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. Übermäßige RAM-Auslastung Dies ist in der Regel mit Listener- oder Mail Flow-Richtlinieneinstellungen verknüpft, die zu viele eingehende Verbindungen oder Injektionen zulassen. Überprüfen Sie die Konfiguration des Listeners, und stellen Sie sicher, dass der maximale Wert für eingehende Verbindungen für die Bereitstellung angemessen ist.

Häufig gestellte Fragen

Was geschieht, wenn meine ESA nicht 11.0.0-264 oder neuer läuft?

Benutzer mit Appliances, auf denen ältere Versionen von AsyncOS ausgeführt werden und die nicht über die Befehlszeilenoption Reparaturwarteschlange mit ausgeblendeter CLI verfügen, können ein Support-Ticket erstellen, um von einem Cisco Support-Techniker Unterstützung bei diesem Verfahren zu erhalten. Ein Support-Tunnel muss geöffnet und für den Cisco Support verfügbar sein, um auf die Appliance zuzugreifen und den Befehl repairqueue auszuführen. Wenden Sie sich an den Cisco Support, um ein aktives Support-Ticket zu erstellen.

Bedeutet eine Beschädigung der Arbeitswarteschlange einen E-Mail-Verlust?

In den meisten Fällen ist Korruption nicht gleichbedeutend mit E-Mail-Verlust. Die Warteschlange ist aufgrund von Metadaten, die sich auf die Nachrichtenverarbeitung beziehen und nicht mehr auf der Appliance vorhanden sind, beschädigt. Hierbei handelt es sich um die Aufzeichnung für die Verarbeitung zwischen Warteschlange, Berichterstellung und Nachrichtenverfolgung. Durch die Ausführung der Reparaturwarteschlange werden die ESA-Metadaten neu erstellt und falsche Meldungen zwischen den Services und der Verarbeitung berichtigt.

Gibt es Auswirkungen auf die Beschädigung von Arbeitswarteschlangen?

Die ESA kann für eine lange Zeit auf einer beschädigten Warteschlange laufen, und die meisten Nachrichten werden immer noch verarbeitet. Die Appliance kann jedoch träge erscheinen, oder einige Meldungen können nie gelöscht werden, wie durch den Wert für die älteste Meldung im Befehl status angegeben wird (dieser ist deutlich älter als der Schwellenwert für Bounce-Konfiguration). Wenn AsyncOS mit einer beschädigten Warteschlange neu startet, kann die Warteschlange nicht bereitgestellt werden. Die Beschädigung kann früher auftreten und unbemerkt bleiben, bis die Appliance neu startet. An diesem Punkt wird die Warteschlange nicht bereitgestellt.

Wie lange kann das Reparaturskript dauern?

Die Reparatur der Arbeitswarteschlange kann zwischen 10 Sekunden und mehreren Stunden dauern, je nach Zustand der ESA und der Anzahl der Nachrichten, die derzeit über eine aktive Arbeitswarteschlange verarbeitet werden. Eine Reparatur der Arbeitswarteschlange auf einer einfachen Appliance mit vollen Warteschlangen zum Zeitpunkt der Beschädigung kann mehrere Stunden dauern.

Was passiert, wenn die Reparaturwarteschlange nicht ausgeführt werden kann oder nicht vollständig ist?

In bestimmten Situationen (z. B. bei einer übervollen Warteschlange auf einer Appliance) kann die Reparaturwarteschlange nicht abgeschlossen werden. Wenn die Reparaturwarteschlange nach 4 Stunden nicht abgeschlossen ist, ist die Warteschlange höchstwahrscheinlich nicht reparierbar, und es genügt, eine neue Warteschlange zu erstellen. Wenden Sie sich bei solchen Problemen an den Cisco Support, um ein aktives Support-Ticket zu erstellen und den Cisco Support zu kontaktieren.

Verwandte Inhalte

• Cisco Email Security Appliance - Benutzerhandbücher
• Cisco Email Security Appliance - Befehlsreferenzen
• In welcher Reihenfolge wird die Verarbeitung in der Arbeitswarteschlange durchgeführt? Was ist die Arbeitswarteschlangen-Pipeline?
• Technischer Support und Dokumentation für Cisco Systeme

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
2.0	02-Oct-2026	Rezertifizierung
1.0	10-Aug-2017	Erstveröffentlichung