Bloqueo del servidor, / var / log / messages informa que "se ha excedido el límite de trabajo acumulado"

9

Tenemos un sistema operativo CentOS que no respondió esta mañana al tráfico de red externo. Es una maquina virtual. Pude reiniciar la VM. Después de volver a iniciar sesión, encontré lo siguiente en el archivo / var / log / messages, repitiendo una y otra vez, hasta el punto del reinicio:

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

Leí en otro foro que el siguiente comando podría identificar la fuente del tráfico acumulado:

[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

¿Alguien puede aconsejarme sobre los próximos pasos que debo tomar para evitar que este problema vuelva a ocurrir? No estoy particularmente familiarizado con el propósito del trabajo atrasado o lo que significa el resultado del informe resumido del evento.

— Hola YWCA
fuente

¿Puedes descartar un problema de almacenamiento? Los registros no se escriben si el almacenamiento es inaccesible, pero el núcleo permanece ejecutándose, al menos por un tiempo.

— the-wabbit

El almacenamiento es local y no ha mostrado signos de problemas. Creo que es más probable que no se registre información útil.

— YWCA Hola

5

Se puede aumentar la cartera de pedidos mediante la modificación -b 320de /etc/audit/audit.rulesalgo más grande y ver si tiene algún efecto, pero estas cantidades nos muestran todavía muy pocos resultados de la auditoría, así que dudo que el error de auditoría tiene nada más que ver con el sistema de congelación en sí mismo. Probablemente sea solo un síntoma de que algo más está sucediendo.

Verifique /var/log/audit/audit.logqué eventos se han registrado para ver si pueden ser de alguna utilidad para su depuración.

— Mattias Ahnberg
fuente

audit.logesencialmente se quedó en silencio aproximadamente 2 horas antes de que notáramos el problema (esto sucedió temprano en la mañana). Luego, los mensajes comenzaron nuevamente con el reinicio. Espero que este no sea otro escenario de congelación de Linux donde no se encuentren respuestas reales de los registros: /

— YWCA Hola,

Tenga en cuenta que en el sistema basado en RHEL7, debe cambiar el archivo /etc/audit/rules.d/audit.rules porque el /etc/audit/audit.rules se reescribe al reiniciar la auditoría.

— Bruno Mairlot

2

Hay múltiples soluciones:

Para alargar la cartera de pedidos, agregue o edite /etc/audit/audit.rulesagregando o editando "-b 320" a "-b 8192".
cambie la prioridad editando priority_boost de 3 a 4 o 5 pulg /etc/audit/auditd.conf.

Para averiguar qué problema causa este problema, ejecute aureport --start today o aureport --start today --event --summary -i

— Esmaeil MIRZAEE
fuente