auditd日志轮转不生效的直接原因是rotate_logs=no未启用或max_log_file/num_logs配置不当；需显式设置rotate_logs=yes、max_log_file（MB）、num_logs，并重启服务验证。
auditd 日志轮转不生效的常见原因
直接原因是 auditd.conf 中轮转配置未启用或参数冲突。默认安装后，max_log_file 和 num_logs 通常为 0 或未设置，导致日志无限追加；同时 rotate_logs 默认是 no，即使其他参数正确，轮转也不会触发。
-
rotate_logs = yes必须显式开启，否则所有轮转参数被忽略 -
max_log_file单位是 MB，设为100表示单个日志文件最大 100MB，超过即触发轮转 -
num_logs控制保留几个历史文件（含当前），设为6表示最多保留audit.log+audit.log.1~audit.log.5 -
flush推荐设为incremental，避免高负载下日志丢失；freq可配合设为20（每 20 条刷一次磁盘）
生产可用的 auditd.conf 轮转模板（直接覆盖）
以下配置适用于中等流量系统（每日审计事件数 ≤ 50 万），兼顾磁盘占用与追溯能力。修改后需重启服务：systemctl restart auditd。
log_file = /var/log/audit/audit.log log_group = audit log_file_mode = 0640 max_log_file = 100 max_log_file_action = rotate space_left = 75 space_left_action = email action_mail_acct = root admin_space_left = 50 admin_space_left_action = halt disk_full_action = halt disk_error_action = syslog rotate_logs = yes num_logs = 6 flush = incremental freq = 20
注意：space_left 和 admin_space_left 是磁盘剩余空间百分比阈值（非 audit 日志自身大小），用于主动预警或保护系统；disk_full_action = halt 在磁盘真正写满前强制停 auditd，防止系统级故障。
验证轮转是否真正工作
光改配置不等于生效。必须确认三点：
- 运行
auditctl -s | grep "enabled"，输出应为enabled 1，表示 auditd 正在运行 - 检查
ls -lt /var/log/audit/，正常应看到audit.log最新，且有.1～.5编号文件（数量 ≤num_logs - 1） - 手动触发一次轮转：
auditctl -r，然后立刻检查文件时间戳和大小变化；若无反应，看journalctl -u auditd -n 20是否报"rotation disabled"类错误
容易被忽略的磁盘压力点
audit 日志膨胀往往不是单一配置问题，而是多个环节叠加：
- 如果启用了
auditctl -a always,exit -F arch=b64 -S execve这类高频规则，max_log_file = 100可能撑不过几小时——先用ausearch -m avc -ts recent | head -20看实际事件密度，再调参 -
/var/log/audit/所在分区若和/合并，audit 日志打满会直接卡死 ssh、systemd-journald 等关键服务 - 某些云主机镜像自带
logrotate对audit.log的接管脚本，和 auditd 原生轮转冲突，需检查/etc/logrotate.d/audit是否存在并禁用
auditd 轮转逻辑是「写满才切」，没有按时间切分的能力；如果需要按天归档或对接 SIEM，得在外部用 inotifywait 监听 audit.log 文件重命名事件，再做搬运或压缩。
