ubuntu inotify为何失效

在 Ubuntu（以及其它 Linux 发行版）上，inotify 失效通常并不是 inotify 本身坏了，而是使用方式或系统限制导致“看起来没反应”。下面按常见原因 → 现象 → 解决办法来说明。

一、最常见原因：inotify 监听数量达到上限

现象

• 某些目录/文件不再触发事件
• 程序报错（常见）：

  ENOSPC: System limit for number of file watchers reached
  

• 常见于：
  • VSCode
  • Webpack / Vite
  • Node / Docker / Electron

原因

inotify 有系统级 watcher 数量限制。

查看当前限制：

cat /proc/sys/fs/inotify/max_user_watches

解决办法（临时）

sudo sysctl fs.inotify.max_user_watches=524288

永久解决

echo 'fs.inotify.max_user_watches=524288' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

二、监听的是“已被替换的文件”（如日志、配置、编辑器保存）

现象

• 文件内容变了，但 inotify 没触发
• 或只触发一次，之后再也不触发

原因

很多程序（如 vim、sed -i、某些日志轮转）是：

1. 删除原文件
2. 创建一个新 inode 的文件

你监听的是旧 inode，所以失效。

解决办法

• 监听目录而不是单个文件
• 使用 IN_MOVED_TO / IN_CREATE 事件
• 或重新注册 watch

三、监听路径在挂载点 / 网络文件系统上

现象

• NFS / SMB / FUSE 目录无事件
• Docker volume 中监听宿主机路径无效

原因

inotify 只能在本地文件系统生效，不支持：

• NFS
• SMB/CIFS
• 某些 FUSE 文件系统

解决办法

• 在文件实际所在的机器上监听
• 对 Docker：
  • 在容器内监听
  • 或使用 --privileged

四、inotify 事件队列溢出

现象

• 批量操作（解压、git checkout）时丢失事件
• 偶尔“卡住”

原因

事件产生速度 > 消费速度，内核丢弃事件。

查看：

cat /proc/sys/fs/inotify/max_queued_events

解决

sudo sysctl fs.inotify.max_queued_events=1048576

五、程序逻辑问题（不是 inotify 的问题）

• 没有调用 read()
• 只监听了 IN_MODIFY 但文件是 IN_CLOSE_WRITE
• 多线程/异步中 watch 被提前释放
• 使用 inotifywait 但参数写错

示例（正确）：

inotifywait -m -e modify,attrib,close_write /path

六、权限问题

现象

• 子目录无事件
• 某些用户监听失败

原因

• 没有目录读权限
• 在容器中没有 CAP_SYS_ADMIN

解决

• 确保对目录有 r-x
• 容器加 --cap-add SYS_ADMIN

七、快速排查 checklist

# 1. 当前 watcher 数量
cat /proc/sys/fs/inotify/max_user_watches

# 2. 实际使用情况
find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | wc -l

# 3. 测试 inotify 是否工作
inotifywait -m /tmp/test

如果你能告诉我：

• 用的什么工具（inotifywait / 程序 / 语言）
• 监听的是文件还是目录
• 是否 Docker / NFS
• 报错信息

我可以直接帮你定位到具体哪一项导致失效。