Penguncian server, / var / log / messages melaporkan “batas simpanan terlampaui”

9

Kami memiliki OS CentOS yang menjadi tidak responsif pagi ini terhadap lalu lintas jaringan eksternal. Ini adalah mesin virtual. Saya dapat me-reboot VM. Setelah masuk kembali, saya menemukan yang berikut ini di file / var / log / messages, berulang-ulang, sampai pada titik reboot:

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

Saya membaca di forum lain bahwa perintah berikut dapat mengidentifikasi sumber lalu lintas jaminan:

[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

Adakah yang bisa menyarankan saya langkah selanjutnya apa yang harus saya ambil untuk mencegah masalah ini terjadi lagi? Saya tidak terlalu familiar dengan tujuan dari jaminan simpanan atau apa arti dari laporan ringkasan acara.

— YWCA Halo
sumber

Bisakah Anda mengesampingkan masalah penyimpanan? Log tidak ditulis jika penyimpanan tidak dapat diakses, tetapi kernel tetap berjalan - setidaknya untuk sementara waktu.

— the-wabbit

Penyimpanan bersifat lokal dan belum menunjukkan tanda-tanda masalah. Saya pikir kemungkinan besar info yang berguna tidak dicatat.

— YWCA Halo

5

Anda dapat meningkatkan backlog dengan memodifikasi -b 320dalam /etc/audit/audit.rulesuntuk sesuatu yang lebih besar dan melihat apakah ia memiliki efek apapun, tetapi ini berjumlah Anda menunjukkan kepada kita masih sangat sedikit hasil audit, jadi aku ragu kesalahan audit yang memiliki sesuatu yang banyak yang harus dilakukan dengan sistem pembekuan itu sendiri. Ini mungkin hanya gejala dari sesuatu yang lain terjadi.

Periksa /var/log/audit/audit.loguntuk melihat peristiwa apa yang telah dicatat untuk melihat apakah mereka dapat digunakan untuk debugging Anda.

— Mattias Ahnberg
sumber

audit.logdasarnya pergi sekitar 2 jam sebelum kami melihat masalah (ini terjadi di pagi hari). Kemudian, pesan mulai lagi dengan reboot. Saya berharap ini bukan skenario pembekuan linux lain di mana tidak ada jawaban nyata ditemukan dari log: /

— YWCA Halo

Perhatikan bahwa pada sistem berbasis RHEL7, Anda perlu mengubah file /etc/audit/rules.d/audit.rules karena aturan /etc/audit/audit.rules akan ditulis ulang saat restart auditd.

— Bruno Mairlot

2

Ada beberapa solusi:

Untuk memperpanjang backlog, tambahkan atau edit /etc/audit/audit.rulesdengan menambahkan atau mengedit "-b 320" menjadi "-b 8192".
ubah prioritas dengan mengedit priority_boost dari 3 menjadi 4 atau 5 in /etc/audit/auditd.conf.

Untuk mencari tahu tentang masalah apa yang menyebabkan masalah ini, jalankan aureport --start today atau aureport --start today --event --summary -i

— Esmaeil MIRZAEE
sumber