We have all been there. You have a compliance requirement to log every execve call across the fleet, so you turn on auditd, write a few aggressive rules, and walk away. Then the production load spikes, the kernel audit buffer overflows, and the system either pauses or starts dropping logs into the void. It is a classic case of security goals fighting against system performance, and usually, the system just silently gives up on the logging.

Why your current log buffer is a ticking time bomb

The kernel audit buffer is fixed by default. If your rules generate events faster than the auditd daemon can drain them to disk, the kernel hits a backlog limit. You have to decide what happens next: do you want the kernel to lock up the entire system to ensure a log is recorded, or do you want to keep the process running and lose the audit trail? The default configuration often tries to be too clever and ends up failing at both.

auditctl -b 8192 -e 2

• Increase the backlog limit to at least 8192 to survive transient bursts
• Set the failure mode to 2 to cause a kernel panic rather than ignoring silent data loss if that is your compliance stance
• Monitor the loss count in the audit status output regularly with auditctl -s

Setting the failure mode to 2 is the nuclear option, but if you work in an environment where an unlogged event is worse than a system crash, it is the only honest way to handle it. Don’t leave your audit backlog at the kernel default of 64 or 320. If you are logging execve or file system watches on a busy box, you are basically begging for an overflow within the first hour of high traffic.

Before you push this to your entire fleet, check your current backlog consumption during peak hours using auditctl -s. If the lost counter is ticking up, you are already losing data, and no amount of log rotation tweaks will fix that fundamental bottleneck.