Stop auditd from drowning your storage when a rogue process goes wild

Technical Briefing | 8/17/2026

You spend all morning configuring audit rules because security wants visibility, only for the disk to fill up by lunch. This bit me in production back when a misconfigured file watch started tracking a high-churn log directory. auditd is essentially a firehose hooked directly into your kernel, and if you don’t constrain it, it’ll eat your root partition for breakfast.

Why the default config is a trap

Most distributions ship with a generic audit.rules file that’s far too chatty for a busy server. The real problem isn’t just the sheer number of events; it’s that auditd keeps logging until it hits an error, then locks the system if you have the failure mode set to email or panic. You want the audit trail, but you need to prioritize system stability over logging every single read on a tmpfs mount.

auditctl -D && auditctl -w /etc/shadow -p wa -k shadow-monitor && auditctl -e 2

• Avoid using -w on directories with high write frequency like /var/log or /tmp.
• Set the auditd log size limit and log group in auditd.conf to prevent log rotation gaps.
• Use -k to label your rules so you can grep for specific events without parsing the entire file.
• Verify your rule count with auditctl -l before assuming everything is active.

Before you apply these changes, check your current backlog with auditctl -s. If that backlog count is climbing, you’re already missing events regardless of your disk space. Tweak your buffer size in the daemon config file until the backlog drops to zero under load. It’s a boring game of cat and mouse, but you’ll thank yourself when you actually need that audit trail during an investigation.