Serverul se blochează, /var/log/messages raportează „limita de backlog depășită” (Administrarea sistemului, Linux, Centos, Jurnal De Evenimente Windows, Audit)

YWCA Bună ziua a intrebat.

Avem un sistem de operare CentOS care a devenit insensibil în această dimineață la traficul de rețea extern. Este o mașină virtuală. Am reușit să repornesc mașina virtuală. După ce m-am logat din nou, am găsit următoarele în fișierul /var/log/messages, care se repetă de mai multe ori, până la momentul repornirii:

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

Am citit pe un alt forum că următoarea comandă ar putea identifica sursa traficului întârziat:

[[email protected] 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

Poate cineva să mă sfătuiască cu privire la următorii pași pe care ar trebui să îi fac pentru a preveni reapariția acestei probleme? Nu sunt deosebit de familiarizat cu scopul backlog-ului sau cu semnificația raportului de rezumat al evenimentelor.

Comentarii

  • Puteți exclude o problemă de stocare? Jurnalele nu sunt scrise dacă stocarea este inaccesibilă, dar kernelul rămâne în funcțiune – cel puțin pentru o perioadă de timp. –  > Por the-wabbit.
  • Stocarea este locală și nu a dat niciun semn de probleme. Cred că este mai probabil ca informațiile utile să nu fie înregistrate. –  > Por YWCA Bună ziua.
2 răspunsuri
Mattias Ahnberg

Puteți crește numărul de întârzieri prin modificarea -b 320 în /etc/audit/audit.rules la ceva mai mare și să vedeți dacă are vreun efect, dar aceste sume pe care ni le arătați încă foarte puține rezultate de audit, așa că mă îndoiesc că eroarea de audit are prea multă legătură cu înghețarea sistemului în sine. Probabil că este doar un simptom al faptului că se întâmplă altceva.

Verificați /var/log/audit/audit.log să vedeți ce evenimente au fost înregistrate pentru a vedea dacă vă pot fi de folos la depanare.

Comentarii

  • audit.log în esență, a fost liniște cu aproximativ 2 ore înainte de a observa problema (acest lucru s-a întâmplat dimineața devreme). Apoi, mesajele au început din nou odată cu repornirea. Sper că acesta nu este un alt scenariu de înghețare a linuxului în care nu se găsesc răspunsuri reale din jurnale :/ -.  > Por YWCA Bună ziua.
  • Rețineți că, pe sistemul bazat pe RHEL7, trebuie să modificați fișierul /etc/audit/rules.d/audit.rules, deoarece fișierul /etc/audit/audit.rules este rescris la repornirea auditd. –  > Por Bruno Mairlot.
Esmaeil MIRZAEE

Există mai multe soluții:

  1. Pentru a prelungi backlog-ul, adăugați sau editați /etc/audit/audit.rules adăugând sau editând de la „-b 320” la „-b 8192”.
  2. modificați prioritatea prin editarea priority_boost de la 3 la 4 sau 5 în /etc/audit/auditd.conf.

Pentru a afla despre ce problemă cauzează această problemă, rulați aureport --start todaysauaureport --start today --event --summary -i