Linux Auditd Log Buffer Overflow Causing Event Loss

Ahmad Ibrahim 60 Reputation points
2026-10-02T08:51:30.02+00:00

Hi everyone,

We’re seeing missing audit events in our security monitoring system when the Linux host is under heavy load. The auditd backlog appears to overflow, and some events are dropped before they can be processed.

What’s the recommended way to tune the backlog_limit in /etc/audit/audit.rules to handle higher event rates without losing audit records? How should we determine an appropriate value based on system workload, CPU/memory capacity, and expected audit event volume? Also, are there any related auditd parameters we should review to prevent buffer overruns?

Appreciate your support!

Windows for business | Windows 365 Business
0 comments No comments

1 answer

Sort by: Most helpful
  1. Jason Nguyen Tran 27,050 Reputation points Independent Advisor
    2026-10-02T09:43:12.06+00:00

    Hello Ahmad Ibrahim,

    Based on the behavior you described, audit event loss during periods of high system activity is commonly associated with the audit backlog queue filling faster than auditd can process records. As a best practice, I recommend increasing the backlog_limit gradually rather than making a large change immediately, while monitoring backlog utilization, CPU consumption, memory usage, and audit event generation rates to validate the impact.

    To determine an appropriate value, start by measuring the peak audit event volume during your busiest workload periods and compare it against the rate at which auditd is able to process and write events. Systems with higher CPU and available memory can generally sustain larger backlog queues, but the optimal setting depends on the specific audit policy and workload characteristics. In addition to backlog_limit, I suggest reviewing related parameters such as backlog_wait_time, rate_limit, flush, freq, and the failure handling options configured in auditd.conf and the audit ruleset.

    It is also important to verify that excessive or redundant audit rules are not generating unnecessary events, as rule optimization can significantly reduce queue pressure. Monitoring kernel audit messages for backlog warnings, dropped events, and queue saturation indicators can help identify whether the bottleneck is event generation, disk I/O, or auditd processing performance. After any tuning changes, I recommend conducting controlled load testing to confirm that the backlog remains within acceptable limits and that no audit records are being dropped under peak conditions.

    I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

    Jason

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.