Updated: 30 September 2026 · Applies to: audit 3.1 and 4.0 on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13
You add rules to a file in /etc/audit/rules.d/, but auditctl -l still shows No rules or the old list. The rules in that folder are not read directly by the kernel: augenrules combines them into /etc/audit/audit.rules, and only that file is loaded. Work through these checks.
1. Load the rules
augenrules --load auditctl -l
augenrules --load builds /etc/audit/audit.rules from all *.rules files in /etc/audit/rules.d/ (in name order) and loads the result. Restarting auditd also does this: service auditd restart on AlmaLinux, Rocky Linux and RHEL (auditd refuses systemctl restart there), or systemctl restart auditd on Ubuntu and Debian.
2. Check for errors in the rules
augenrules --check auditctl -R /etc/audit/audit.rules
A rule with an error stops the loading at that line, so everything after it is missing. Common mistakes are a system call that does not exist on the architecture, a watched path that does not exist, or a missing -F arch=b64. Files that do not end in .rules are ignored.
3. Are the rules locked?
auditctl -s | grep enabled
enabled 2 means the configuration is immutable: a rules file ends with -e 2 (for example a file named 99-finalize.rules), and no rule can be changed until the next reboot. That is intended on hardened servers. Reboot to load the new rules.
4. Is auditd running?
systemctl status auditd auditctl -s
enabled 0 means auditing is switched off, for example with audit=0 on the kernel command line. Check with cat /proc/cmdline.
5. Test the rule
Trigger an event that your rule should catch and search for its key, for example for a rule with -k time-change:
ausearch -k time-change -i --start recent
For more examples, see how to monitor system time changes with auditd and how to use auditd to monitor a specific system call.
Official documentation: augenrules manual and audit.rules manual.
