Stop leaving your auditd rules wide open to log rotation gaps

Technical Briefing | 10/18/2026

You probably spent an afternoon tuning your auditd rules to capture every execve call across your fleet. It feels great until you realize your log rotation script just nuked the most recent audit logs before the remote aggregator had a chance to suck them down. This bit me in prod when we were trying to reconstruct an unauthorized configuration change and found a glaring hole exactly where our rotation logic fired.

Why the default rotation logic is a trap

Most people rely on the default auditd configuration, which handles log rotation based on size or time. But the integration with logrotate or the internal auditd mechanism often conflicts with your external logging pipeline. If your transport agent depends on file descriptors or specific file paths, a standard logrotate move operation leaves you with a race condition. The kernel keeps writing to the old inode while the aggregator is sitting there waiting for new data, or worse, both lose the stream entirely.

auditctl -e 2 && /sbin/service auditd rotate && auditctl -e 1

• Auditd locks its own configuration when the immutable flag is set via auditctl -e 2
• The rotate command must be issued explicitly to trigger a clean file handoff
• Always verify that your remote shipper is watching the directory or the specific audit.log file before running rotation scripts

If you are running auditd in immutable mode, you can’t just slap a reload command into a cron job. You have to handle the rotation precisely or the daemon will hold onto the file handle and eventually fill up your disk partition. It’s a classic case of kernel-level persistence fighting against user-space convenience. Next time you verify your logs, check the timestamps on your rotated files and ensure they actually align with your audit ingestion metrics.