Solucionar problemas da fila de trabalho usando o comando Repairqueue no ESA

Introdução

Este documento descreve o uso do comando oculto CLI repairqueue no Cisco Email Security Appliance (ESA) e como validar a recuperação da fila.

Problema

Motivos para executar o comando repairqueue:

• Erro ao informar que a fila de trabalho não está montada. Isso geralmente é o resultado da corrupção da fila após um ciclo de energia inadequado ou reinicialização do dispositivo.
• Um defeito conhecido pode exigir esse comando como uma solução alternativa (como o bug da Cisco ID CSCuw2284 - A fila de e-mail é corrompida após um travamento do serviço de processamento de e-mail ou desligamento inadequado).
• Falhas de aplicativos, como as que fazem referência a gcq.py, ou ao subsistema de gerenciamento de filas.
• Detalhes do status ou fila de trabalho > taxa reporta números negativos.

• Status ou Status Detail reporta um valor de Mensagem Mais Antiga que excede o limite de perfil de devolução configurado.

  • Limite padrão: 259200 segundos (3 dias).
  • Para verificar o limite, insira bounceconfig > edit e selecione o perfil Default. Localize a linha. Insira o número máximo de segundos que uma mensagem pode permanecer na fila antes de ser devolvida com hard.

Motivos para não executar o comando repairqueue:

• O processamento lento da fila de trabalho não é um motivo válido para executar um reparo de fila. Os administradores frequentemente confundem o processamento lento da fila de trabalho com a corrupção da fila. Uma fila de trabalho lenta geralmente se deve ao processamento repetido da mesma mensagem, ou de várias mensagens, porque um serviço está utilizando excessivamente os recursos do sistema. Esses cenários de processamento repetido geralmente não são reparados simplesmente executando repairqueue. É necessária uma solução de problemas adicional do serviço ou serviços afetados.

Ambiente

As informações neste documento são baseadas nestas versões de software e hardware:

• ESA, todos os dispositivos virtuais e de hardware que executam AsyncOS 11.0.0-264 ou mais recente

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Em redes ativas, confirme o impacto potencial de cada comando antes de continuar.

A Cisco recomenda o conhecimento destes tópicos:

• Capacidade do sistema, monitoramento do sistema, integridade do sistema e processamento geral de mensagens através da fila de trabalho do ESA.
• Administração geral do ESA.

Note: Consulte o Guia do usuário do ESA ou a Ajuda on-line da GUI do ESA para obter detalhes.

Resolução

O comando CLI repairqueue não corrige todos os problemas da fila de trabalho ou danos. O utilitário tenta um reparo de melhor esforço da fila de trabalho.

1. Execute detalhes de status e confirme se a fila de trabalho mostra sintomas já descritos na Ocorrência, como valores negativos ou um problema de montagem da fila.
2. Execute workqueue e escolha a opção Rate. Confirme se as taxas relatadas oferecem suporte à condição de gatilho.
3. Compare o valor Mensagem mais antiga em status ou detalhe de status com o limite de perfil de devolução configurado. Se o valor exceder o limite, continue com o procedimento de reparo.

aviso: A execução de repairqueue pode resultar na perda de mensagens ativas na fila de trabalho.

4. Execute repairqueue. O primeiro processo executa solicitações de permissão uma vez para continuar e executar o reparo:

   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.

   Note: Em um ESA virtual, ignore a saída, "Waiting for the queue to mount: Não foi possível abrir o dispositivo em /dev/ipmi0 ou /dev/ipmi/0 ou /dev/ipmidev/0: Nenhum arquivo ou diretório" documentado sob a ID de bug Cisco CSCuz28415 com defeito conhecido.

5. Quando o processo de reparo for concluído e a fila de trabalho for reparada, o equipamento manterá um ponto de verificação antigo da fila de trabalho anterior. Para continuar a gravar um novo ponto de verificação para o processamento da fila de trabalho, execute repairqueue novamente e insira o comando para Limpar:

   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. Execute o comando status detail na CLI ou escolha Monitor > System Status na GUI. Confirme se o status do sistema é Online.
7. Revise os logs de e-mail para confirmar o processamento de e-mail. Na CLI, execute o comando tail mail_logs.
8. Execute o comando workqueue e escolha a opção Rate (padrão de 10 segundos). Confirme se as taxas de entrada e saída são razoáveis para o fluxo de mensagens atual. Se a fila de trabalho tiver uma grande lista de pendências, pode levar tempo para ser esvaziada.

Causa

As causas comuns de corrupção da fila de trabalho incluem:

1. Reinicializações inesperadas ou desligamentos inadequados (por exemplo, interrupções de energia). Dependendo dos processos de back-end em execução no momento, a fila pode ficar corrompida ou falhar ao ser montada após a reinicialização. Nesse caso, o CLI pode relatar erros como:

   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. Utilização excessiva de memória (RAM). Geralmente, isso é associado às configurações de política de fluxo de e-mail ou ouvinte que permitem muitas conexões de entrada ou injeções. Revise listenerconfig e confirme se o valor máximo de conexões de entrada é apropriado para a implantação.

FAQ

E se meu ESA não estiver executando 11.0.0-264 ou mais recente?

Os usuários que têm dispositivos executando versões mais antigas do AsyncOS que não têm a opção de comando CLI repairqueue oculto podem abrir um caso de suporte para que um engenheiro de suporte da Cisco ajude com o procedimento. Um túnel de suporte precisa ser aberto e estar disponível para que o Suporte da Cisco acesse o dispositivo e execute o comando repairqueue. Entre em contato com o Suporte da Cisco para abrir um caso de suporte ativo.

Corrupção da fila de trabalho significa perda de e-mail?

Na maioria dos casos, a corrupção não é igual à perda de correspondência. A fila está corrompida devido a metadados relacionados ao processamento de mensagens que não estão mais no aplicativo. Isso é um registro para processamento entre a fila, relatórios e rastreamento de mensagens. A execução de repairqueue recria os metadados do ESA e elimina qualquer erro de relatório entre os serviços e o processamento.

Há alguma repercussão na corrupção da fila de trabalho?

O ESA pode ser executado por muito tempo em uma fila corrompida e a maioria das mensagens ainda é processada. No entanto, o equipamento pode parecer lento ou algumas mensagens nunca podem ser limpas, conforme indicado pelo valor de Mensagem mais antiga no comando status (significativamente mais antigo que o limite bounceconfig). Quando o AsyncOS é reiniciado com uma fila corrompida, a fila pode falhar ao ser montada. A corrupção pode ocorrer mais cedo e permanecer despercebida até que o dispositivo seja reiniciado, momento em que a fila não será montada.

Quanto tempo o script de reparo pode levar para ser concluído?

O reparo da fila de trabalho pode levar de 10 segundos a várias horas, dependendo do estado do ESA e de quantas mensagens estão sendo processadas atualmente por meio de uma fila de trabalho ativa. Um reparo de fila de trabalho em um dispositivo de extremidade inferior com filas cheias no momento da corrupção pode levar várias horas.

O que acontece se a fila de reparo não puder ser executada ou não for concluída?

Em determinadas situações (por exemplo, uma fila cheia demais em um dispositivo), a fila de reparo não pode ser concluída. se repairqueue não for concluída após 4 horas, a fila provavelmente não poderá ser reparada e o único recurso será criar uma nova fila. Para esses problemas avançados, entre em contato com o Suporte da Cisco para abrir um caso de suporte ativo e obter ajuda do Suporte da Cisco.

Conteúdo relacionado

• Guias do usuário final do Cisco Email Security Appliance
• Referências de comandos do Cisco Email Security Appliance
• Qual é a ordem de processamento na fila de trabalho? O que é o pipeline da fila de trabalho?
• Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões

Revisão	Data de publicação	Comentários
2.0	02-Oct-2026	Recertificação
1.0	10-Aug-2017	Versão inicial