Stop getting burned by SELinux denials you can’t even see

Technical Briefing | 9/2/2026

You spend all morning debugging a failed service startup. You check the systemd logs, you look at the app logs, and there’s nothing. No stack trace, no error message, just a clean exit status. That’s when you remember SELinux is running in enforcing mode. You grep through /var/log/audit/audit.log, and it’s empty, even though you are certain the kernel is blocking your process. It’s frustrating, but it usually comes down to one specific oversight.

The hidden buffer that hides your mistakes

What’s actually happening is that auditd isn’t getting to the events before they get dropped or throttled by the kernel backlog. If your audit rules are too verbose, or if the system is under heavy load, the kernel buffer fills up and starts tossing events to keep the system stable. You’re effectively flying blind while the kernel silently nukes your troubleshooting data. You can check if this is happening by looking at the audit backlog stats.

auditctl -s

• Check the backlog_limit to see how many events your buffer can hold before dropping packets
• Watch the backlog counter while you trigger the failed action to see if it spikes to the limit
• If you see the lost field increasing, your auditd service is either overwhelmed or blocked

If you find you are hitting these limits, don’t just blindly increase the backlog. It consumes kernel memory and can trigger an OOM if you aren’t careful. The right approach is to audit only what you actually need. Most people turn on auditing for system calls like execve and then wonder why their logging subsystem collapses under the weight of every single process launch on the host. Be surgical with your audit rules, or you will eventually chase a ghost that isn’t there because the kernel decided it wasn’t important enough to log.