这很完美：
$ inotifywait --event create ~/foo
Setting up watches.
Watches established.
/home/ron/foo/ CREATE bar
然而，当在 /sys/devices/virtual/net 下创建目录 tun0 时，它就在那里。
$ inotifywait --event create /sys/devices/virtual/net
Setting up watches.
Watches established.
由于这些文件夹是世界可读的，我希望 inotifywait 能够工作。
那么，我做错了什么？
谢谢
答案1
虽然inotify 常见问题解答意味着部分支持：
问：我可以观看 sysfs（procfs、nfs...）吗？
简单地说：是的，但有一些限制。这些限制因内核版本而异，并且往往会变得更小。请阅读有关特定文件系统的信息。
它实际上并没有说明可能支持什么（或者在哪个内核版本中，因为这主要取决于文件系统本身而不是库/实用程序中的 inotify 支持）。
一个简单的解释是支持 inotify 并没有真正意义一切in /sys(或/proc) 因为它们不会按照传统意义上被修改。大多数这些文件/目录代表内核状态的快照当你查看它们时。
考虑/proc/uptime一个简单的例子，它包含精确到厘秒的正常运行时间。 inotify 是否应该每秒通知您 100 次它已被“写入”？除了不是很有用之外，它还可能是一个性能问题，也是一个需要解决的棘手问题，因为没有任何东西可以代表这些虚构的“写入”生成 inotify 事件。内核中的inotify在文件系统 API 级别工作。
那么情况是这样的一些sysfs 和 procfs 中的东西确实会生成 inotify 事件，/proc/uptime例如会告诉您何时访问它（访问、打开、关闭），但在我的内核上，/proc/mounts当安装和卸载文件系统时根本不显示任何事件。
以下是 Greg Kroah-Hartman 的看法：
http://linux-fsdevel.vger.kernel.narkive.com/u0qmXPFK/inotify-sysfs 和莱纳斯：
http://www.spinics.net/lists/linux-fsdevel/msg73955.html
（不过这两个线程都是 2014 年的）
为了解决您眼前的问题，您可以使用 dbus，例如dbus-monitor --monitor --system（无需 root）将在创建和删除的 tun 设备上显示触发器（尽管我的不显示 tun 设备名称，仅显示带有 PtP 的 HAL 字符串）知识产权）；udevadm monitor（无需root）；或退回到轮询目录（尝试：用于监视共享文件夹中新文件的脚本（Windows 主机、Linux 来宾））。 （udev您还可以使用inotifywait -m -r /dev/.udev并留意以“n”开头的文件，但这是一个相当糟糕的黑客行为。）
答案2
/sys并且/proc不是文件系统。它们是内核接口，其作用类似于文件系统。
创建网络设备时，不会创建文件系统文件夹。当数据更改时，即使没有人查看，普通文件系统也会更改。但/sys和的内容/proc是在有人查看它的那一刻就创建的。
您需要的是例如udev事件（运行脚本）。