Stop auditd from filling your disk before you actually need those logs

Technical Briefing | 8/1/2026

Most sysadmins enable auditd because a compliance checklist told them to. They set it up, walk away, and forget that the kernel is dutifully writing every single syscall to a partition that is now slowly drowning. I’ve spent more Saturday nights than I care to admit cleaning up a crashed production database because the disk hit 100 percent capacity while logging every open call on an abandoned backup script.

The default configuration is a trap

The standard policy shipped with most distros is far too chatty. If you are auditing file access in high-traffic directories or logging syscalls for every ephemeral container task, you’re just burning I/O for data you’ll never query. You need to switch from recording everything to targeting only the mutations that actually matter. If you are logging execve for the sake of it, you’re asking for trouble.

auditctl -a always,exit -F arch=b64 -S execve -k sensitive_actions

• Set space_left_action to email or exec to prevent a surprise hard stop when disk gets tight.
• Use -F auid>=1000 to filter out root noise and focus on user-space activity.
• Prune your audit rules to ignore high-frequency syscalls like getuid or close if they aren’t part of your security baseline.

When you finally get an alert that the disk is hitting the threshold, don’t just clear the logs. Check what rule is the loudest using ausearch or just grep the logs for the top count of syscalls. If you don’t track your own noisy rules, you are just waiting for the next outage to happen. Take ten minutes to tune these now, and you won’t have to troubleshoot why your server stopped accepting writes at 3 AM.