Server blockiert, / var / log / messages meldet "Backlog-Limit überschritten"

9

Wir haben ein CentOS-Betriebssystem, das heute Morgen nicht mehr auf externen Netzwerkverkehr reagiert. Es ist eine virtuelle Maschine. Ich konnte die VM neu starten. Nachdem ich mich wieder angemeldet hatte, fand ich Folgendes in der Datei / var / log / messages, das sich bis zum Neustart immer wieder wiederholte:

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

Ich habe in einem anderen Forum gelesen, dass der folgende Befehl die Quelle des Backlog-Verkehrs identifizieren kann:

[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

Kann mir jemand raten, welche nächsten Schritte ich unternehmen sollte, um zu verhindern, dass dieses Problem erneut auftritt? Ich bin nicht besonders vertraut mit dem Zweck des Backlogs oder der Bedeutung der Ausgabe des Ereigniszusammenfassungsberichts.

— YWCA Hallo
quelle

Können Sie ein Speicherproblem ausschließen? Protokolle werden nicht geschrieben, wenn auf den Speicher nicht zugegriffen werden kann, aber der Kernel läuft - zumindest für eine Weile.

— The-Wabbit

Die Lagerung ist lokal und weist keine Anzeichen von Problemen auf. Ich denke, es ist wahrscheinlicher, dass nützliche Informationen nicht protokolliert werden.

— YWCA Hallo

5

Sie können den Rückstand erhöhen, indem Sie ihn -b 320in /etc/audit/audit.rulesetwas Größeres ändern und prüfen, ob er Auswirkungen hat. Diese Beträge zeigen uns jedoch immer noch sehr wenige Prüfergebnisse. Ich bezweifle, dass der Prüfungsfehler viel mit dem Einfrieren des Systems an sich zu tun hat. Es ist wahrscheinlich nur ein Symbol dafür, dass etwas anderes passiert.

Überprüfen Sie /var/log/audit/audit.log, welche Ereignisse protokolliert wurden, um festzustellen, ob sie für Ihr Debugging von Nutzen sind.

— Mattias Ahnberg
quelle

audit.logIm Wesentlichen wurde es ungefähr 2 Stunden still, bevor wir das Problem bemerkten (dies geschah am frühen Morgen). Dann wurden die Nachrichten beim Neustart erneut gestartet. Ich hoffe, dass dies kein weiteres Linux-Freeze-Szenario ist, in dem keine wirklichen Antworten aus den Protokollen gefunden werden: /

— YWCA Hallo

Beachten Sie, dass Sie auf einem RHEL7-basierten System die Datei /etc/audit/rules.d/audit.rules ändern müssen, da die Datei /etc/audit/audit.rules beim Neustart von auditd neu geschrieben wird.

— Bruno Mairlot

2

Es gibt mehrere Lösungen:

Um den Rückstand zu verlängern, fügen Sie ihn hinzu oder bearbeiten Sie /etc/audit/audit.rulesihn, indem Sie "-b 320" zu "-b 8192" hinzufügen oder bearbeiten .
Ändern Sie die Priorität, indem Sie priority_boost von 3 auf 4 oder 5 Zoll bearbeiten /etc/audit/auditd.conf.

Um herauszufinden, welches Problem dieses Problem verursacht, führen Sie aureport --start today oder aus aureport --start today --event --summary -i

— Esmaeil MIRZAEE
quelle