auditd日志占满磁盘时，audit_backlog_limit完全失效，必须依赖space_left等空间管理配置；disk_full_action=HALT会直接关机，logrotate需配合USR1信号通知auditd重开日志。
Auditd 日志占满磁盘是常见但高风险的问题，轻则审计日志丢失，重则触发 HALT 导致系统直接关机（尤其在 Azure 或加固环境中）。排查要从“空间异常表现”切入，快速定位是否 auditd 是元凶，并验证其配置与行为是否失控。
看磁盘使用和日志路径占用是否错位
执行 df -h 和 du -sh /var/log/audit/* 对比：
- 若
df显示根分区或/var分区使用率 ≥95%，但du统计的 audit 目录总和远小于此（比如 df 报 100%，du 只算出 2GB），说明有已删除但句柄未释放的日志文件——auditd 进程仍在往已删的audit.log写入 - 若
du结果接近df，且/var/log/audit/下存在多个大文件（如audit.log.1～.12都是百MB级），说明轮转没生效或保留过多 - 特别注意：
ls -l /var/log/audit/中若看到audit.log大小为 0，但lsof -n | grep audit.log显示它仍被 auditd 持有，这就是典型的“删了没 reload”问题
查 auditd 配置是否启用危险动作
打开 /etc/audit/auditd.conf，重点检查这几行：
-
disk_full_action = HALT或admin_space_left_action = HALT：这是最常导致 VM 启动失败的配置。一旦磁盘触达阈值，auditd 会强制关机而非告警 -
max_log_file_action = IGNORE：错误设置！应为ROTATE，否则日志超限时 auditd 继续追加写入，极易撑爆磁盘 -
space_left和admin_space_left是否过小（如设成 100M 或 50M）：建议分别设为500M和100M，留出缓冲窗口
验 logrotate 是否真正通知 auditd 重开日志
auditd 不自动响应 logrotate，默认轮转后仍往旧文件描述符写——必须靠 USR1 信号刷新。确认以下三点：
- logrotate 配置中是否含
postrotate ... kill -USR1 $(cat /var/run/auditd.pid 2>/dev/null) ... endscript或等效的sharedscripts + postrotate ... USR1 - 手动触发一次轮转测试：
sudo logrotate -f /etc/logrotate.d/auditd，再看/var/log/audit/audit.log时间戳是否更新、大小是否归零 - 检查
ps aux | grep auditd输出中的启动参数，确认没有--no-rotate类禁用选项
盯住 auditd 进程本身是否异常膨胀
内存泄漏也会间接引发磁盘问题（如因 OOM 触发内核 panic 清理不彻底，或 auditd 卡死导致日志堆积）：
- 运行
top -p $(pgrep auditd)，观察 RES 内存是否持续上涨（如从 200MB 涨到 2GB+） - 用
lsof -p $(pgrep auditd) | wc -l查打开文件数，正常应在 10～30；若 >500，说明日志文件句柄未正确关闭 - 检查
/var/log/messages或journalctl -u auditd是否频繁报Cannot write to disk、Out of memory或Failed to rotate log
