inotify无法触发事件是因为文件被彻底删除后watch自动移除，且auditd不会自动重建日志文件；需通过SIGHUP重载配置恢复监控，或用audit规则记录删除行为。
audit.log 被删后 inotify 无法触发事件的原因
inotify 对已删除的文件句柄会立即失效，IN_DELETE_SELF 事件只在文件被 unlink 但仍有进程打开时触发；一旦 /var/log/audit/audit.log 被外部进程（如 logrotate、恶意脚本）彻底删除且 auditd 未重开日志文件，inotify watch 就自动移除，后续写入也不会恢复监控。
常见错误现象：inotifywait -m -e delete_self /var/log/audit/audit.log 在文件被删后静默退出，或直接报 No such file or directory。
- auditd 默认使用
log_file配置项指定日志路径，但不保证文件存在时才打开 —— 它会在启动时创建，但不会在运行中自动重建被删文件 - 即使你用
IN_MOVED_TO监控目录，也捕获不到audit.log被删后的新文件名（比如audit.log.1），因为 rename 不等于 recreate - Linux 内核 5.10+ 对 inotify 的 watch 限制更严格，重复 add_watch 可能因
ENOSPC失败，需检查/proc/sys/fs/inotify/max_user_watches
用 inotifywait + auditd 重启实现有限恢复
真正可行的“恢复”不是自动重建文件，而是检测删除后强制 auditd 重新打开日志文件。这依赖 auditd 支持 SIGHUP 重载配置（默认开启），且日志路径在 /etc/audit/auditd.conf 中是静态路径（非带时间戳的轮转路径）。
一个最小可用监控脚本逻辑：
#!/bin/bash LOG="/var/log/audit/audit.log" CONF="/etc/audit/auditd.conf"while true; do if [[ ! -f "$LOG" ]]; then
文件消失：先确保目录存在，再发信号让 auditd 重建
mkdir -p "$(dirname "$LOG")" killall -HUP auditd 2>/dev/null # 等 auditd 重开（通常 < 1s），再继续监控 sleep 0.5fi
仅当文件存在时才加 watch，避免 inotifywait 报错退出
inotifywait -q -e delete_self "$LOG" 2>/dev/null && { echo "$(date): $LOG was deleted, triggering auditd reload" >> /var/log/audit/watcher.log } done
- 不能依赖
inotifywait -m长期运行，必须在外层用 while 循环兜底判断文件是否存在 -
killall -HUP auditd比systemctl reload auditd更快，且不依赖 systemd；但需确保 auditd 进程名确实是auditd（RHEL 8+ 可能为auditd.service） - 该方案对 logrotate 的正常轮转无效 —— 因为 logrotate 默认用
copytruncate或create，不会真删原文件；只有暴力rm才触发
比 inotify 更可靠的替代方案：auditd 自身规则 + ausearch
与其监控文件系统事件，不如用 auditd 的内核级审计能力记录谁删了它。在 /etc/audit/rules.d/immutable.rules 中添加：
-a always,exit -F path=/var/log/audit/audit.log -F perm=w -k audit_log_delete
然后执行 augenrules --load。之后任何进程对该文件的 unlink、rename、truncate 操作都会被记录。
- 用
ausearch -i -k audit_log_delete可查到完整调用栈，包括 UID、PID、命令行参数 - 该规则不受文件是否存在的影响 —— audit 规则基于路径字符串匹配，只要路径字段一致就生效
- 注意：如果攻击者先删规则再删日志（
auditctl -D），这条规则就失效；所以应设为 immutable：echo "auditctl -e 2" >> /etc/rc.local
audit.log 删除后能否完全恢复内容？
不能。auditd 不缓存未写入磁盘的日志，一旦文件被删且 auditd 未及时重开，正在 buffer 中的日志条目就永久丢失。唯一可能保留部分数据的场景是：
- auditd 开启了
flush = incremental且freq = 20（默认），意味着最多丢最近 20 条 - 文件被删前刚完成一次 sync，而内核 page cache 还没刷盘 —— 此时从
/proc/kcore或内存镜像中可能恢复，但实操门槛极高，不具通用性 - 系统启用了
auditd的 remote logging（如tcp_client），那日志副本在远端服务器上
所以重点永远在「防止删」和「快速告警」，而不是幻想恢复。
