Blocco server, / var / log / messages segnala "limite di backlog superato"

9

Abbiamo un sistema operativo CentOS che questa mattina non ha risposto al traffico di rete esterno. È una macchina virtuale. Sono stato in grado di riavviare la VM. Dopo aver effettuato nuovamente l'accesso, ho trovato quanto segue nel file / var / log / messages, ripetendo più volte, fino al punto del riavvio:

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

Ho letto su un altro forum che il seguente comando potrebbe identificare l'origine del traffico di backlog:

[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

Qualcuno può consigliarmi quali sono i prossimi passi da fare per evitare che si ripresenti questo problema? Non conosco particolarmente lo scopo del backlog o il significato dell'output del report di riepilogo degli eventi.

— Ciao YWCA
fonte

Puoi escludere un problema di archiviazione? I log non vengono scritti se l'archiviazione è inaccessibile, ma il kernel rimane in esecuzione, almeno per un po '.

— the-wabbit il

Lo spazio di archiviazione è locale e non ha mostrato segni di problemi. Penso che sia più probabile che non vengano registrate informazioni utili.

— YWCA Ciao,

5

È possibile aumentare l'arretrato modificando -b 320in /etc/audit/audit.rulesqualcosa di più grande e vedere se ha qualche effetto, ma tali importi ci mostri ancora molto pochi i risultati degli audit, quindi dubito l'errore di revisione ha qualcosa a che fare con il sistema di congelamento in sé. Probabilmente è solo un sintomo di qualcos'altro che sta accadendo.

Controlla /var/log/audit/audit.logper vedere quali eventi sono stati registrati per vedere se possono essere utili al tuo debug.

— Mattias Ahnberg
fonte

audit.logsostanzialmente si è zittito circa 2 ore prima di notare il problema (questo è accaduto al mattino presto). Quindi, i messaggi sono stati riavviati con il riavvio. Spero che questo non sia un altro scenario di blocco di Linux in cui non si trovano risposte reali dai registri: /

— YWCA Ciao

Si noti che sul sistema basato su RHEL7, è necessario modificare il file /etc/audit/rules.d/audit.rules poiché il file /etc/audit/audit.rules viene riscritto al riavvio di auditd.

— Bruno Mairlot,

2

C'è una soluzione multipla:

Per allungare il backlog, aggiungere o modificare /etc/audit/audit.rulesaggiungendo o modificando "-b 320" in "-b 8192".
cambia la priorità modificando la priorità_punto da 3 a 4 o 5 pollici /etc/audit/auditd.conf.

Per sapere quale problema causa questo problema, esegui aureport --start today o aureport --start today --event --summary -i

— Esmaeil MIRZAEE
fonte