You probably have an audit rule watching sensitive config files. It works great until you start logging enough events to notice the kernel backing up its own queues. If you are just piping everything to the default dispatcher, you are eventually going to see your processes hang or experience mysterious dropouts during peak load. This bit me in prod when a high-traffic web server started stuttering because the audit backlog limit was hit, causing the kernel to halt syscalls until the log daemon could catch up.

Why the default backlog setting is a landmine

The kernel puts audit events into a fixed-size buffer. When that fills up, the default behavior is to fail close, meaning it pauses the process triggering the event until space clears. You need to adjust the backlog limit to survive spikes without stalling your application code, or you risk turning your security oversight into a denial-of-service vector.

auditctl -b 8192

• Check /var/log/audit/audit.log for backlog overflow errors before bumping the memory
• Set the failure mode to print a kernel panic or error if you are in an ultra-secure environment, but use 0 or 1 for standard servers to avoid system-wide lockups
• Monitor the auditd queue using auditctl -s to see how often you are nearing your hard limit during normal traffic patterns

Check your ruleset for generic recursive watches on busy directories, as those are usually the culprits behind runaway audit volumes. If you find yourself needing to increase the backlog limit into the tens of thousands, you are probably logging too much and should rethink what is actually worth auditing versus what is just noise. Next time you are troubleshooting a phantom latency spike in your application, check the audit backlog before you burn hours in strace.