Linux fanotify 监控目录为什么看不到文件内容：事件掩码与读取时机

用 Linux fanotify 盯着上传目录时，最容易误判的一点是：事件通知告诉你的主要是“哪个文件发生了什么动作”，并不会把文件正文塞进通知队列。要拿到内容，必须根据事件类型和文件描述符再走一次打开、读取或延后核对的路径。

FAN_EVENT_ON_CHILD 只负责把目录下的直接子项纳入观察范围；真正读取内容要看事件是否提供可用文件描述符、访问时机是否合适，以及监听进程是否有权限再次打开目标。

fanotify_init 和 fanotify_mark 分别负责什么

排查“怎么没有内容”之前，先把两个容易混在一起的调用拆开。fanotify_init 返回一个文件描述符，它代表内核里的事件队列；后续程序对这个描述符调用 read，才会拿到 fanotify_event_metadata 等记录。

fanotify_mark 决定在哪个目录、挂载点或文件系统上监听，以及监听哪些事件。下面这个最小片段只表达调用关系，不把它当成可直接复制到生产环境的完整守护进程：

fd = fanotify_init(FAN_CLASS_NOTIF, O_RDONLY | O_LARGEFILE);
fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
              FAN_OPEN_PERM | FAN_CLOSE_WRITE, AT_FDCWD, "/srv/upload");
read(fd, buffer, sizeof(buffer));

这里的 fd 不是目标文件本身，而是 fanotify 队列。read 取出通知后，程序还要根据事件掩码判断它是打开请求、写入关闭，还是其他文件系统动作。把这个队列描述符直接当成业务文件去读，得到的当然不会是正文。

FAN_EVENT_ON_CHILD 为什么看不到深层文件

如果标记的是 /srv/upload，再加上 FAN_EVENT_ON_CHILD，它观察的是这个目录的直接子项。/srv/upload/a.txt 可以触发，/srv/upload/2026/a.txt 则不会因为父目录的这个标记自动递归触发。要覆盖完整目录树，应考虑标记挂载点或文件系统，或者为需要的目录分别建立标记。

另一个误区是把“创建”理解成“内容已经可读”。上传程序可能先创建临时文件，再分段写入，最后改名；监听到 FAN_CREATE 时，文件可能还是空的。更稳妥的判断通常是等待 FAN_CLOSE_WRITE，然后再做大小、权限和内容格式检查。

mask = FAN_CREATE | FAN_CLOSE_WRITE | FAN_EVENT_ON_CHILD;
fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_ONLYDIR,
              mask, AT_FDCWD, "/srv/upload");

如果监听的是权限事件，FAN_OPEN_PERM 代表“有人请求打开”，监听程序必须写回允许或拒绝的决定；它不是一个可以忽略的普通通知。相反，普通通知读出后应及时关闭事件里提供的文件描述符，避免监听进程自身耗尽句柄。

真正需要文件内容时，应该把读取放在哪里

用权限事件拦截打开，而不是提前解析正文

安全扫描需要在文件打开前做决定时，可以使用 FAN_OPEN_PERM。这条路径的重点是快速判断和及时回复，不能把慢速的全文解析塞进权限事件处理里，否则会把打开动作一起拖住。解析任务更适合交给后续队列。

用 FAN_CLOSE_WRITE 作为稳定性检查点

如果目标是“文件写完后再读取”，FAN_CLOSE_WRITE 更贴近这个语义。收到事件后先确认事件记录里是否有可用文件描述符，再读取或重新打开目标；随后检查文件大小是否稳定、是否仍在监听目录、是否符合业务格式。不要只凭一次 FAN_CREATE 就把文件送进解析器。

用日志把事件与业务结果对应起来

建议至少记录事件掩码、目标路径或文件句柄、读取结果和解析状态。日志中把“收到通知”和“内容校验通过”分成两个状态，才能区分监听配置错误、文件尚未写完，以及监听进程没有权限读取这三类问题。

常见问题

fanotify 能直接把文件正文放进事件里吗？

不能把普通事件理解成正文传输。事件主要提供元数据，某些初始化方式会提供文件描述符或文件句柄，正文仍要由监听程序自行读取。

FAN_EVENT_ON_CHILD 会递归监听所有子目录吗？

不会。它针对标记目录的直接子项；完整目录树需要标记更高层的挂载点或文件系统，或逐级增加标记。

为什么 FAN_CREATE 后马上读取经常是空文件？

创建和写入完成不是同一个时刻。上传程序可能仍在写数据，应该结合 FAN_CLOSE_WRITE 或业务侧的完成标记再读取。

权限事件不回复会怎样？

FAN_OPEN_PERM 属于需要作出允许或拒绝决定的事件。处理程序必须写回响应，否则目标访问可能一直等待，排查时应优先检查回复路径和异常退出。

把“收到事件”和“读到正文”分成两次验收

fanotify 的排查顺序可以固定成两层：第一层确认 fanotify_init、fanotify_mark 和 read 能稳定收到正确掩码；第二层再确认目标文件已完成写入、监听进程有读取权限，并用独立的内容校验结果结束任务。这样看到一条事件时，不会误以为正文已经准备好，也不会用递归监听的假设掩盖实际的目录边界。