Uso do repairqueue do comando

Introdução

Este documento descreve o uso hidden do repairqueue do comando CLI e das ações que ocorre quando este o comando é emitido do CLI de uma ferramenta de segurança do email de Cisco (ESA).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Potencialidade de sistema, monitoramento de sistema, saúdes de sistema, e processamento total das mensagens através do workqueue ESA.
• A administração total ESA.

Nota: Consulte por favor o Guia do Usuário ESA ou a ajuda online do ESA GUI para uns detalhes mais adicionais.

Componentes Utilizados

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

• ESA, todo o hardware e dispositivos virtuais executando AsyncOS 11.0.0-264 ou mais novo

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

Razões executar o comando do repairqueue:

• Erro que indica que o workqueue não está montado. Este é geralmente um resultado do ciclo da potência da corrupção da fila ou da repartição cargo-imprópria do dispositivo.
• O defeito conhecido exige este como uma ação alternativa (tal como CSCuw22284 - a fila do email corrompe depois que os hermes causam um crash ou fechamento impróprio).
• Falhas do aplicativo, tais como aqueles que proveem “gcq.py”, ou o subsistema do gerenciamento de fila.
• O detalhe ou o workqueue > a taxa do estado estão relatando números negativos.
• Estado ou relatórios de detalhes “a mensagem a mais velha” do estado mais velha do que seu perfil do salto. O valor padrão para este é 3 dias. Você pode verificar do bounceconfig > edita e escolhe o perfil padrão. Você será procurar “entra por favor no número máximo de segundos onde uma mensagem pode ficar na fila antes de ser” a linha duramente saltada, que é à revelia 259200 segundos, ou os 3 dias. Isto exclui os domínios virtuais da entrega, the.<destination>.queue tal como the.cpq.queue, the.euq.queue, the.cpq.release.host.

Razões não executar o comando do repairqueue:

• O processamento lento do workqueue não é um motivo válido executar um reparo da fila. Os administradores confundem frequentemente o workqueue lento que processa como a corrupção da fila. Um workqueue lento é geralmente devido repetir o processamento das mesmas mensagens devendo prestar serviços de manutenção à sobre-utilização dos recursos de sistema. Frequentemente estas repetidas processando encenações não são as coisas que são reparadas simplesmente executando o repairqueue. Um Troubleshooting mais adicional dos serviços que uma mensagem “estaria pendurada” sobre durante o processamento seria exigido.

Uso do repairqueue do comando

Executar o repairqueue do comando CLI não pode reparar todas as edições ou corrupções do workqueue. Esta utilidade faz um melhor esforço para reparar o workqueue.

aviso: Os administradores ESA devem tomar a nota, lá são a possibilidade de perder mensagens ativa de um workqueue.

Ao executar o repairqueue, a primeira corrida do processo alertará para a permissão continuar e executar uma vez 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.

Nota: Em um ESA virtual, ignore a seguinte saída, o defeito conhecido (CSCuz28415): “Esperando a fila para montar: Não podiam abrir o dispositivo em /dev/ipmi0 ou /dev/ipmi/0 ou /dev/ipmidev/0: No Such File or Directory (mensagem de erro)”

Uma vez que o processo de reparo é terminado, o workqueue estará reparado, porém o dispositivo ainda reterá um ponto de verificação velho do workqueue precedente. A fim recomeçar escrever um ponto de verificação novo para o workqueue que processa, execute o repairqueue outra vez, e emita o comando 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

Uma vez que o repairqueue é terminado, faça por favor cada um do seguinte a fim validar o workqueue é para trás em linha e o dispositivo está processando o correio:

1. Verifique o status de sistema executando o comando detail do estado do CLI, ou o monitor > o status de sistema do GUI.  O dispositivo deve refletir um status de sistema do Online.  
2. Reveja o correio entra o dispositivo para assegurar o correio que processa como esperado.  Isto pode ser realizado do CLI executando o comando dos mail_logs da cauda.
3. Execute o comando do workqueue do CLI, escolhendo a opção da taxa com taxa padrão dos segundos 10. Enquanto o dispositivo está processando o correio dentro e/ou o correio para fora, a taxa os segundos cada 10 deve ser razoavelmente igual para a relação da “entrada/saída”. Os dispositivos que têm um grande durante o processamento do workqueue podem tomar algum tempo para esvaziar para fora o workqueue, e recomeçam o processamento normal.

FAQ

Que se meu ESA não está executando 11.0.0-264 ou mais novo?

Os clientes que têm os dispositivos que executam umas versões mais velhas de AsyncOS que não tenham a opção do comando CLI do repairqueue hidden devem abrir um caso de suporte a fim ter uma assistência do engenheiro de suporte da Cisco.  Um túnel do apoio precisará de estar aberto e disponível para que o apoio de Cisco alcance o dispositivo e execute o processo da fila do reparo.  Contacte por favor o apoio de Cisco para abrir um caso de suporte ativo.

O meio da '' corrupção” do workqueue envia a perda?

Na maioria dos casos, a corrupção não iguala a perda do correio. A fila é corrompido devido ao meta-DATA relativo ao processamento de mensagem que está já não no dispositivo. Esta é uma contabilidade que processa entre a fila e o relatório, rastreamento de mensagem, etc. que executa o repairqueue reconstruirá o ESA meta-DATA e limpeza que misreporting entre os serviços e o processamento.

Há alguma repercussão à corrupção do workqueue?

O ESA pode poder ser executado por muito tempo em uma fila corrompida e a maioria de mensagens podem processar muito bem, mas o dispositivo pode parecer lento, ou determinadas mensagens podem nunca cancelar para fora, como indicado “pela mensagem a mais velha” no comando status --- significativamente mais velho do que o bounceconfig deve reservar. Quando AsyncOS é reiniciado realmente com uma fila corrompida, a fila pode ou não pode poder montar. A corrupção pode ter ocorrido há algúm tempo e parece ser multa até que o dispositivo esteja reiniciado, que no ponto é incapaz de montar a fila.

Que causas enfileiram a corrupção?

Duas a maioria de causas comum da “da corrupção fila” são:

1. Repartições inesperadas do dispositivo. As interrupções da potência ou manter o botão da potência conduzirão a um fechamento impróprio e podem corromper a fila, segundo que processos backend estavam fazendo naquele tempo. O dispositivo pode recuperar e a fila pode vir apoio corrompido, ou a fila não pode ser montável em cima da repartição. Se isto é verdadeiro, os administradores ESA verão da “os alertas não montados e/ou o “demônio fila” que não respondem” ao executar o estado do 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. uso de RAM do Para fora--limite pelo dispositivo.  Isto é causado muito provavelmente por um misconfiguration das políticas do fluxo do ouvinte e/ou de correio, visto geralmente com demasiado os muitos a conexão de entrada/injeções permitidas. Cisco recomenda rever seu listenerconfig para conexões de entrada máximas. Cisco recomenda este seja ajustado em 300.

Quanto tempo deve o reparo passar pelo processo de script toma para terminar?

Reparar o workqueue pode tomar em qualquer lugar dos segundos 10 a diversas horas, segundo o estado do ESA e quanto a mensagem está processando atualmente através de um workqueue ativo. Um reparo do workqueue no dispositivo mais baixo da gama com as filas cheias na altura da corrupção poderia tomar diversas horas.

Que acontece se o repairqueue não pode ser executado ou faz não completo?

Em determinadas situações, (por exemplo, fila sobre-FULL em um dispositivo) o repairqueuewill para não poder terminar. Se os repairqueuedoes não terminam após 4 horas, a fila é muito provavelmente irreparável e o único recurso é construir uma fila nova executando hidden o resetqueue do comando CLI. Para edições avançadas, contacte por favor CiscoSupport para abrir um caso de suporte ativo e para ter Cisco apoie a assistência.

Informações Relacionadas

• Cisco envia por correio eletrónico guias do utilizador final da ferramenta de segurança
• Cisco envia por correio eletrónico referências de comandos da ferramenta de segurança
• Uso do resetqueue do comando
• Que é a ordem de processamento na fila de trabalho? Que é o encanamento da fila de trabalho?
• Suporte Técnico e Documentação - Cisco Systems