audit_backlog_wait_time 仅在 backlog 队列满但未超 audit_backlog_limit 时生效；一旦触发“backlog limit exceeded”，内核直接丢弃事件，该参数完全不参与流程。
audit.log 写满时 audit_backlog_wait_time 不生效？先看内核是否真在等
很多运维遇到 audit.log 满盘、auditd 停写、系统响应变慢甚至卡死，第一反应是调大 audit_backlog_wait_time。但实际中这个参数常常“没用”——因为内核根本没走到等待逻辑。它只在 backlog 队列满且 audit_backlog_limit（注意不是 backlog_limit）未被突破时才起作用；一旦队列溢出触发丢弃策略（auditctl -e 2 锁定后默认丢弃），内核就直接 drop event，连等都不等。
验证方法：
auditctl -s | grep -E "(backlog|enabled)"确认当前
backlog_limit 值和 enabled 状态；再查 dmesg | grep audit，若看到 audit: backlog limit exceeded，说明已丢弃，audit_backlog_wait_time 此时完全不参与流程。
backlog_limit 和 audit_backlog_wait_time 的真实作用边界
backlog_limit 是内核 audit subsystem 中的硬队列长度（单位：条目数），默认 8192；audit_backlog_wait_time 是每个 audit 事件在队列中最多等待的微秒数（us），默认 6000000（即 6 秒）。两者配合逻辑如下：
- 当 audit 队列未满，新事件入队，不触发等待或丢弃
- 当队列已满，且
audit_backlog_wait_time > 0，内核会循环尝试等待空位，超时则丢弃该事件 - 若
audit_backlog_wait_time == 0，队列一满就立即丢弃（最激进） - 若
audit_backlog_wait_time （如 -1），表示无限等待——但这极易导致进程 hang 住，尤其在高 syscall 频率场景（如编译、容器启动）
关键点：backlog_limit 控制容量，audit_backlog_wait_time 控制单次等待耐心，但**不控制日志落盘速度**。日志写满本质是 auditd 处理慢 + 磁盘空间不足 + 规则太宽泛，调这两个参数只是“缓震”，不是根治。
audit.log 爆满时真正该优先检查的三件事
别急着改内核参数。先确认以下三项，它们比调 audit_backlog_wait_time 更直接影响系统是否卡死：
-
auditctl -l查规则数量和匹配频率——一条-a always,exit -F arch=b64 -S execve在 busy 进程上每秒可产数百事件 -
ls -lh /var/log/audit/audit.log+df -h /var/log/audit确认磁盘是否真满，以及 logrotate 是否失效（检查/etc/logrotate.d/auditd和systemctl status logrotate） -
ps aux | grep auditd看auditd进程是否 zombie 或 high CPU，再用strace -p $(pgrep auditd) -e trace=write,fsync看它是否卡在写磁盘或 sync 上
常见陷阱：把 backlog_limit 调到 65536 后发现卡得更狠——因为大量事件堆积在内存队列里，反而加剧内存压力和调度延迟。
临时缓解与长期配置建议
若已卡死，优先执行：
- 手动轮转日志：
service auditd rotate或auditctl -R /etc/audit/rules.d/*.rules（重载规则清空队列） - 紧急限流：
auditctl -e 1（设置为不可修改但允许丢弃），再auditctl -s | grep enabled确认返回值为 1 - 缩小规则范围：删掉
-F key=以外的宽泛规则，尤其是无-F arch=限定的execve监控
长期配置必须同步做三件事：启用 logrotate 的 delaycompress 和 maxsize、在 /etc/audit/auditd.conf 中设 max_log_file = 50M 和 num_logs = 5、用 auditctl -e 2 锁定规则防误操作。内核参数只作为兜底：建议 backlog_limit = 16384，audit_backlog_wait_time = 1000000（1 秒），避免无限等待。
真正难处理的是那些既不能关 audit、又必须全量记录 execve 的合规场景——这时 backlog 参数调优只是表象，背后得靠异步日志转发（如 auditd + audispd + kafka）或 eBPF 替代方案来解耦内核事件生产与用户态消费。
