O servidor bloqueado, / var / log / messages relata "limite de atraso excedido"

9

Temos um sistema operacional CentOS que deixou de responder esta manhã ao tráfego de rede externa. É uma máquina virtual. Consegui reiniciar a VM. Depois de efetuar login novamente, encontrei o seguinte no arquivo / var / log / messages, repetindo várias vezes, até o ponto da reinicialização:

Jan 21 06:53:01 PBX kernel: audit: backlog limit exceeded
Jan 21 06:53:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: printk: 8 messages suppressed.
Jan 21 06:54:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: audit: audit_lost=1130 audit_rate_limit=0 audit_backlog_limit=320

Li em outro fórum que o seguinte comando pode identificar a origem do tráfego da lista de pendências:

[root@PBX log]# aureport --start today --event --summary -i

Event Summary Report
======================
total  type
======================
486  USER_ACCT
486  CRED_ACQ
486  USER_START
485  LOGIN
477  CRED_DISP
477  USER_END
6  USER_LOGIN
3  USER_AUTH
2  CONFIG_CHANGE
2  CRED_REFR
1  DAEMON_START

Alguém pode me aconselhar sobre os próximos passos que devo tomar para impedir que esse problema ocorra novamente? Não estou particularmente familiarizado com o objetivo da lista de pendências ou com o significado da saída do relatório de resumo do evento.

— YWCA Hello
fonte

Você pode descartar um problema de armazenamento? Os logs não são gravados se o armazenamento estiver inacessível, mas o kernel permanece em execução - pelo menos por um tempo.

— the-wabbit 23/01

O armazenamento é local e não mostrou sinais de problemas. Eu acho que é mais provável que informações úteis não estejam sendo registradas.

— YWCA Olá

5

Você pode aumentar o atraso, modificando -b 320em /etc/audit/audit.rulesalgo maior e ver se ele tem algum efeito, mas esses valores que nos mostram ainda muito poucos resultados da auditoria, por isso duvido que o erro de auditoria tem qualquer coisa a ver com o sistema de congelamento em si. Provavelmente é apenas um sintoma de algo mais acontecendo.

Verifique /var/log/audit/audit.logpara ver quais eventos foram registrados para ver se eles podem ser úteis para sua depuração.

— Mattias Ahnberg
fonte

audit.logessencialmente ficou quieto cerca de 2 horas antes de percebermos o problema (isso aconteceu no início da manhã). Em seguida, as mensagens foram iniciadas novamente com a reinicialização. Espero que este não seja outro cenário de congelamento do linux em que nenhuma resposta real seja encontrada nos logs: /

— YWCA Hello

Observe que no sistema baseado em RHEL7, você precisa alterar o arquivo /etc/audit/rules.d/audit.rules porque o /etc/audit/audit.rules é reescrito na reinicialização do auditd.

— Bruno Mairlot

2

Há várias soluções:

Para aumentar a lista de pendências, adicione ou edite /etc/audit/audit.rulesadicionando ou editando "-b 320" em "-b 8192".
altere a prioridade editando priority_boost de 3 para 4 ou 5 pol /etc/audit/auditd.conf.

Para descobrir qual problema causa esse problema, execute aureport --start today ou aureport --start today --event --summary -i

— Esmaeil MIRZAEE
fonte