サーバーがロックアップし、/ var / log / messagesが「バックログ制限を超えました」と報告する

9

今朝、外部ネットワークトラフィックに応答しなくなったCentOS OSがあります。これは仮想マシンです。VMを再起動できました。再度ログインすると、/ var / log / messagesファイルに次の項目が見つかり、再起動の時点まで何度も繰り返しました。

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

別のフォーラムで、次のコマンドでバックログトラフィックのソースを特定できることを確認しました。

[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

この問題が再発しないようにするには、次の手順について誰かにアドバイスしてもらうことはできますか？バックログの目的や、イベントサマリーレポートの出力が何を意味するのか、私は特に詳しくありません。

— YWCAこんにちは
ソース

ストレージの問題を除外できますか？ストレージにアクセスできない場合、ログは書き込まれませんが、カーネルは実行されたままです-少なくともしばらくの間。

— the-wabbit 2012年

ストレージはローカルで、問題の兆候はありません。有用な情報が記録されていない可能性が高いと思います。

— YWCA Hello

5

何か大きなものに変更-b 320し/etc/audit/audit.rulesてバックログを増やし、効果があるかどうかを確認することもできますが、これらの量ではまだ監査結果がほとんどないので、監査エラーがシステム自体のフリーズと関係があるのではないかと思います。それはおそらく、何か他のことが起こっていることの兆候にすぎません。

/var/log/audit/audit.logログに記録されているイベントを確認して、デバッグに役立つかどうかを確認します。

— マティアス・アンバーグ
ソース

audit.log問題に気づく約2時間前に基本的に静かになりました（これは早朝に起こりました）。その後、メッセージは再起動とともに再開しました。これが、ログから実際の回答が見つからない別のLinuxフリーズシナリオではないことを願っています：/

— YWCA Hello

RHEL7ベースのシステムでは、/ etc / audit / audit.rulesがauditdの再起動時に書き換えられるため、ファイル/etc/audit/rules.d/audit.rulesを変更する必要があることに注意してください。

— Bruno Mairlot、2015年

2

複数の解決策があります：

バックログを長くするには、/etc/audit/audit.rules「-b 320」から「-b 8192」を追加または編集して、追加または編集します。
でpriority_boostを3から4または5に編集して、優先度を変更し/etc/audit/auditd.confます。

この問題の原因となっている問題を見つけるには、aureport --start today またはを実行します。 aureport --start today --event --summary -i

— Esmaeil MIRZAEE
ソース