Máy chủ khóa, báo cáo / var / log / message vượt quá giới hạn backlog

9

Chúng tôi có một hệ điều hành CentOS đã không phản hồi sáng nay với lưu lượng truy cập mạng bên ngoài. Nó là một máy ảo. Tôi đã có thể khởi động lại VM. Sau khi đăng nhập lại, tôi tìm thấy phần sau trong tệp / var / log / message, lặp đi lặp lại nhiều lần, cho đến thời điểm khởi động lại:

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

Tôi đọc trên một diễn đàn khác rằng lệnh sau có thể xác định nguồn của lưu lượng tồn đọng:

[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

Bất cứ ai có thể tư vấn cho tôi những bước tiếp theo tôi nên làm để ngăn chặn vấn đề này xảy ra lần nữa? Tôi không đặc biệt quen thuộc với mục đích tồn đọng hoặc ý nghĩa đầu ra của báo cáo tóm tắt sự kiện.

— Xin chào
nguồn

Bạn có thể loại trừ một vấn đề lưu trữ? Nhật ký không được ghi nếu bộ nhớ không thể truy cập được, nhưng kernel vẫn chạy - ít nhất là trong một thời gian.

— the-wợi

Lưu trữ là cục bộ và không có dấu hiệu rắc rối. Tôi nghĩ nhiều khả năng thông tin hữu ích không được ghi lại.

— YWCA Xin chào

5

Bạn có thể tăng việc tồn đọng bằng cách sửa đổi -b 320trong /etc/audit/audit.rulesmột cái gì đó lớn hơn và xem nếu nó có bất kỳ tác dụng, nhưng những số tiền bạn chỉ cho chúng ta vẫn còn rất ít kết quả kiểm toán, vì vậy tôi nghi ngờ lỗi kiểm toán có bất cứ điều gì nhiều việc phải làm với hệ thống làm lạnh của riêng mình. Nó có lẽ chỉ là một triệu chứng của một cái gì đó khác xảy ra.

Kiểm tra /var/log/audit/audit.logxem những sự kiện nào đã được ghi lại để xem liệu chúng có thể được sử dụng để gỡ lỗi của bạn không.

— Mattias Ahnberg
nguồn

audit.logvề cơ bản đã im lặng khoảng 2 giờ trước khi chúng tôi nhận thấy vấn đề (điều này xảy ra vào sáng sớm). Sau đó, tin nhắn bắt đầu lại với khởi động lại. Tôi hy vọng đây không phải là một kịch bản đóng băng linux khác mà không có câu trả lời thực sự nào được tìm thấy từ nhật ký: /

— YWCA Xin chào

Lưu ý rằng trên hệ thống dựa trên RHEL7, bạn cần thay đổi tệp /etc/audit/rules.d/audit.rules vì /etc/audit/audit.rules được viết lại khi khởi động lại audd.

— Bruno Mairlot

2

Có nhiều giải pháp:

Để kéo dài thời gian tồn đọng, thêm hoặc chỉnh sửa /etc/audit/audit.rulesbằng cách thêm hoặc chỉnh sửa "-b 320" thành "-b 8192".
thay đổi mức độ ưu tiên bằng cách chỉnh sửa ưu tiên_boost từ 3 thành 4 hoặc 5 in /etc/audit/auditd.conf.

Để tìm hiểu về vấn đề gây ra vấn đề này, hãy chạy aureport --start today hoặc aureport --start today --event --summary -i

— Esmaeil MIRZAEE
nguồn