Stop letting auditd logs fill your disk and crash your node

Technical Briefing | 9/29/2026

We all know auditd is a requirement for compliance, but nobody warns you that its default configuration is essentially a time bomb. I once saw a production box go into a read-only state because the audit logs ballooned during a massive log-rotate event that coincided with a kernel panic dump. It is the kind of failure that turns a routine compliance check into an emergency recovery mission at 3 AM.

Why the defaults are killing your uptime

The issue is simple. If your partition for var log audit fills up and you have not explicitly set an action for disk full, the system defaults to whatever the kernel feels like doing. Often, that means hanging the system or dropping you into a panic state to protect the integrity of the audit trail. You have to decide now what matters more: your uptime or your compliance logs.

sed -i 's/^disk_error_action = .*/disk_error_action = SYSLOG/' /etc/audit/auditd.conf
service auditd restart

• Set disk_error_action to SYSLOG so errors hit your central log server instead of freezing the kernel
• Adjust space_left_action to email you or alert your monitoring stack long before you hit 100 percent
• Never set the action to HALT unless you are working in a military-grade air-gapped facility where a log gap is worse than a hard crash

Check your space_left setting too. If you are logging every execve call across a dozen microservices, the default threshold is likely too low to give you a meaningful reaction time. Tighten this up and offload these logs to a remote collector immediately. If you leave them local, you are just waiting for a disk failure you cannot easily undo.