Introdução
Este documento descreve o uso do comando oculto CLI repairqueue e as ações que ocorrem quando este comando é emitido a partir da CLI de um Cisco Email Security Appliance (ESA).
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha 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.
Observação: consulte o Guia do usuário do ESA ou a Ajuda on-line da GUI do ESA para obter mais detalhes.
Componentes Utilizados
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. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Problema
Motivos para executar o comando repairqueue:
- Erro ao informar que a fila de trabalho não está montada. Isso geralmente é resultado da corrupção da fila após o ciclo de energia inadequado ou da reinicialização do dispositivo.
- Um defeito conhecido requer isso como uma solução alternativa (como CSCuw2284 - A fila de e-mail corrompe após o travamento de hermes ou o 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 estão relatando números negativos.
- Status ou Status Detail relata "Mensagem mais antiga" mais antiga que seu perfil de devolução. O valor padrão é 3 dias. Você pode verificar em bounceconfig > edit e escolher o perfil padrão. Você procurará a linha "Insira o número máximo de segundos que uma mensagem pode permanecer na fila antes de ser devolvida por hardware", que por padrão é de 259200 segundos ou 3 dias. Isso exclui os domínios de entrega virtual, a fila.<destino>.como o .cpq.queue, o .euq.queue, o .cpq.release.host.
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 de filas de trabalho com corrupção de filas. Uma fila de trabalho lenta geralmente ocorre devido ao processamento repetido da(s) mesma(s) mensagem(ns) devido à subutilização de serviço dos recursos do sistema. Muitas vezes, esses cenários de processamento repetidos não são coisas que são reparadas simplesmente executando repairqueue. Seria necessário Troubleshoot mais sobre o(s) serviço(s) no(s) qual(is) uma mensagem seria "suspensa" durante o processamento.
Uso do comando repairqueue
A execução do comando CLI repairqueue pode não reparar todos os problemas ou danos da fila de trabalho. Este utilitário faz o melhor esforço para reparar a fila de trabalho.
Aviso: os administradores do ESA devem observar que existe a possibilidade de perder mensagens ativas de uma fila de trabalho.
Ao executar repairqueue, a primeira execução do processo solicitará permissão uma vez para continuar e executar o reparo:
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.
Observação: em um ESA virtual, ignore a seguinte saída, defeito conhecido (CSCuz28415): "Waiting for the queue to mount: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or diretory" (Aguardando a montagem da fila: não foi possível abrir o dispositivo em /dev/ipmi0 ou /dev/ipmi/0 ou /dev/ipmidev/0: não existe esse arquivo ou diretório)
Quando o processo de reparo for concluído, a fila de trabalho será reparada, mas o equipamento ainda 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 a fila de reparo novamente e emita o comando para Limpar:
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
Verificar
Quando a fila de reparo for concluída, execute cada um dos procedimentos a seguir para validar se a fila de trabalho está novamente on-line e se o equipamento está processando e-mails:
- Verifique o status do sistema executando o comando status detail na CLI ou Monitor > System Status na GUI. O equipamento deve refletir o status do sistema de Online.
- Revise os logs de e-mail no equipamento para garantir o processamento de e-mail conforme esperado. Isso pode ser feito a partir da CLI executando o comando tail mail_logs.
- Execute o comando workqueue na CLI, escolhendo a opção Rate com a taxa padrão de 10 segundos. Enquanto o dispositivo estiver processando e-mails recebidos e/ou enviados, a taxa a cada 10 segundos deve ser razoavelmente igual para a proporção "Entradas/Saídas". Os aplicativos que têm uma grande fila de trabalho de processamento pendente podem demorar algum tempo para esvaziar a fila de trabalho e retomar o processamento normal.
FAQ
E se meu ESA não estiver executando 11.0.0-264 ou mais recente?
Os clientes que têm dispositivos executando versões mais antigas do AsyncOS que não têm a opção de comando CLI repairqueue oculto devem abrir um caso de suporte para que um engenheiro de suporte da Cisco ajude. Um túnel de suporte precisará ser aberto e estar disponível para que o Suporte da Cisco acesse o dispositivo e execute o processo de fila de reparo. Entre em contato com o Suporte da Cisco para abrir um caso de suporte ativo.
A "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. Trata-se de um processamento de contabilidade entre a fila e os relatórios, o controle de mensagens etc. A execução da fila de reparo recriará os metadados do ESA e eliminará qualquer relatório incorreto entre os serviços e o processamento.
Há alguma repercussão na corrupção da fila de trabalho?
O ESA pode ser capaz de ser executado por um longo tempo em uma fila corrompida e a maioria das mensagens pode ser processada corretamente, mas o dispositivo pode parecer lento, ou certas mensagens podem nunca apagar, como indicado pela "Mensagem mais antiga" no comando status — significativamente mais antiga do que o bounceconfig deve permitir. Quando o AsyncOS é realmente reiniciado com uma fila corrompida, a fila pode ou não ser capaz de montar. A corrupção pode ter ocorrido há algum tempo e parece estar boa até que o equipamento seja reiniciado, momento em que não é possível montar a fila.
O que causa a corrupção da fila?
As duas causas mais comuns de 'corrupção de fila' são:
- Reinicializações inesperadas do equipamento. Interrupções de energia ou manter o botão liga/desliga pressionado resultarão em um desligamento incorreto e poderão corromper a fila, dependendo do que os processos de back-end estavam fazendo no momento. O dispositivo pode se recuperar e a fila pode voltar corrompida, ou a fila pode não ser montada na reinicialização. Se isso for verdadeiro, os administradores do ESA verão alertas de "fila não montada" e/ou "daemon não respondendo" ao executar o status a partir da 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
- Uso de RAM fora de limite pelo dispositivo. Isso é provavelmente causado por uma configuração incorreta das políticas de ouvinte e/ou fluxo de e-mail, geralmente visto com muitas conexões de entrada/injeções permitidas. A Cisco recomenda revisar sua configuração de ouvinte para obter o máximo de conexões de entrada. A Cisco recomenda que seja definido como 300.
Quanto tempo o script de reparo deve 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, fila cheia demais em um dispositivo), a fila de reparo não poderá ser concluída. Se a fila de reparo 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 executando o comando oculto da CLI resetqueue. Para problemas avançados, entre em contato com o Suporte da Cisco para abrir um caso de suporte ativo e obter assistência do Suporte da Cisco.
Informações Relacionadas
Feedback