来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习文章相关编程知识。下面本篇文章就来带大家聊聊《inotify监控与日志恢复方法》，介绍一下，希望对大家的知识积累有所帮助，助力实战开发！

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"
<p>while true; do
if [[ ! -f "$LOG" ]]; then</p><h1>文件消失：先确保目录存在，再发信号让 auditd 重建</h1><pre class="brush:python;toolbar:false;">mkdir -p "$(dirname "$LOG")"
killall -HUP auditd 2>/dev/null
# 等 auditd 重开（通常 < 1s），再继续监控
sleep 0.5

fi

仅当文件存在时才加 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），那日志副本在远端服务器上

所以重点永远在「防止删」和「快速告警」，而不是幻想恢复。

终于介绍完啦！小伙伴们，这篇关于《inotify监控与日志恢复技巧》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！