这非常有效：

$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可以工作.

那么,我做错了什么？

谢谢

解决方法:

虽然the inotify FAQ意味着部分支持：

Q: Can I watch sysfs (procfs, nfs…)?

Simply spoken: yes, but with some limitations. These limitations vary between kernel versions and tend to get smaller. Please read information about particular filesystems.

它实际上并没有说明可能支持的内容(或者在哪个内核版本中,因为这主要取决于文件系统本身的inotify支持,而不是库/实用程序).

一个简单的解释是,在/ sys(或/ proc)中支持inotify并不真正有意义,因为它们没有按照传统意义进行修改.大多数这些文件/目录代表了查看它们时内核状态的快照.

将/ proc / uptime视为一个简单的例子,它包含精确到厘秒的正常运行时间. inotify应该每秒100次通知你它被“写”到？除了不是非常有用之外,它既是性能问题又是棘手的问题,因为没有任何东西代表这些虚构的“写入”产生inotify事件.在内核中inotify works at the filesystem API level.

那么情况就是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 IP的HAL字符串); udevadm监视器(不需要是root用户);或者回退到轮询目录(尝试：script to monitor for new files in a shared folder (windows host, linux guest)).
(使用udev你也可以使用inotifywait -m -r /dev/.udev并注意以“n”开头的文件,但这是一个非常糟糕的黑客攻击.)