Moin moin FreeBSDs file monitoring via kqueue/kevent requires files to be opened to be monitored. This has a few draw back which mostly crop up in desktop systems (gnome, kde, ...) that have support for monitoring and indexing the users home directory. Issue 1: A big ~ leads to file handle exhaustion As all files have to be opened the kern.maxfiles sysctl needs to be tuned by users. => desktops won't work out of the box for those users => unnecessary crashes happening on startup of desktop sessions Issue 2: Socket files cannot be monitored As open() cannot be called on socket files, you cannot monitor a socket file for its deletion. Linux's file monitoring seems to be able to support these use cases -- maybe a re-implementation of their file monitoring should be considered inside FreeBSD. An other option would probably be to extend kqueue for these use cases. mfg Tobias
Regarding issue 2, it's now possible to open unix sockets with open(O_PATH): https://cgit.freebsd.org/src/commit/?id=2bd9826995ca6b23f8b088cfa035c0ad1c578ac3 For now kevent() on such fds is not permitted, but I think we could enable EVFILT_VNODE events on them as was done for named pipes recently: https://cgit.freebsd.org/src/commit/?id=7259ca31048e5ced8e7f90657a3d7084aeafdf51 Would that be sufficient here?
I cannot answer the question if this change would suffice, but this is another example of the kqueue limitations causing issues for users: https://github.com/syncthing/syncthing/issues/7855 Syncthing has shipped an in-app notification so bsd users know they may slow their system down due to this. As somebody who uses syncthing server-side on freebsd... I would love to see something helping this :D
There's a documentation aspect to bug 256269 comment 1: * the absence of a package message for sysutils/kf5-baloo * the FreeBSD Handbook …
This is an issue that I've been struggling with lately too, also with syncthing. The kqueue workaround works for smaller directory trees, but is unworkable for large collections of files. The number of file descriptors can be increased, but with millions of files to watch, the system quickly becomes unusable. There was at least one previous attempt to add inotify-type functionality to FreeBSD in a GSoC project, but I don't know what happened with that: https://www.freebsd.org/status/report-2010-04-2010-06.html#File-System-Changes-Notification A long-running discussion on the forums of the differences between inotify (Linux), fsevents (Mac), and kqueue is here: https://forums.freebsd.org/threads/inotify-for-freebsd.38162/page-3 I also wonder if something could be implemented based on the existing audit framework, which seems to allow file alterations to be watched, although it doesn't have an easy API to use from code.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f1f230439fa48581f40a57f095627f667a9713c3 commit f1f230439fa48581f40a57f095627f667a9713c3 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2025-07-03 20:07:45 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2025-07-04 14:42:33 +0000 vfs: Initial revision of inotify Add an implementation of inotify_init(), inotify_add_watch(), inotify_rm_watch(), source-compatible with Linux. This provides functionality similar to kevent(2)'s EVFILT_VNODE, i.e., it lets applications monitor filesystem files for accesses. Compared to inotify, however, EVFILT_VNODE has the limitation of requiring the application to open the file to be monitored. This means that activity on a newly created file cannot be monitored reliably, and that a file descriptor per file in the hierarchy is required. inotify on the other hand allows a directory and its entries to be monitored at once. It introduces a new file descriptor type to which "watches" can be attached; a watch is a pseudo-file descriptor associated with a file or directory and a set of events to watch for. When a watched vnode is accessed, a description of the event is queued to the inotify descriptor, readable with read(2). Events for files in a watched directory include the file name. A watched vnode has its usecount bumped, so name cache entries originating from a watched directory are not evicted. Name cache entries are used to populate inotify events for files with a link in a watched directory. In particular, if a file is accessed with, say, read(2), an IN_ACCESS event will be generated for any watched hard link of the file. The inotify_add_watch_at() variant is included so that this functionality is available in capability mode; plain inotify_add_watch() is disallowed in capability mode. When a file in a nullfs mount is watched, the watch is attached to the lower vnode, such that accesses via either layer generate inotify events. Many thanks to Gleb Popov for testing this patch and finding lots of bugs. PR: 258010, 215011 Reviewed by: kib Tested by: arrowd MFC after: 3 months Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D50315 share/man/man4/rights.4 | 10 +- sys/bsm/audit_kevents.h | 1 + sys/conf/files | 1 + sys/fs/nullfs/null_subr.c | 4 + sys/fs/nullfs/null_vnops.c | 29 +- sys/kern/kern_resource.c | 21 + sys/kern/subr_capability.c | 4 + sys/kern/sys_generic.c | 35 +- sys/kern/syscalls.master | 15 + sys/kern/vfs_cache.c | 59 +++ sys/kern/vfs_default.c | 17 + sys/kern/vfs_inotify.c (new) | 1008 ++++++++++++++++++++++++++++++++++++++++++ sys/kern/vfs_subr.c | 7 +- sys/kern/vfs_vnops.c | 3 +- sys/kern/vnode_if.src | 21 + sys/sys/caprights.h | 2 + sys/sys/capsicum.h | 8 +- sys/sys/exterr_cat.h | 1 + sys/sys/file.h | 1 + sys/sys/inotify.h (new) | 146 ++++++ sys/sys/resourcevar.h | 4 + sys/sys/specialfd.h | 5 + sys/sys/user.h | 5 + sys/sys/vnode.h | 12 +- sys/tools/vnode_if.awk | 1 + 25 files changed, 1405 insertions(+), 15 deletions(-)
I think we should close this now?
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=296d7f95aab8d3c948fd6a421eb49513aa48435b commit 296d7f95aab8d3c948fd6a421eb49513aa48435b Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2025-07-03 20:07:45 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2026-08-05 15:15:14 +0000 vfs: Initial revision of inotify Add an implementation of inotify_init(), inotify_add_watch(), inotify_rm_watch(), source-compatible with Linux. This provides functionality similar to kevent(2)'s EVFILT_VNODE, i.e., it lets applications monitor filesystem files for accesses. Compared to inotify, however, EVFILT_VNODE has the limitation of requiring the application to open the file to be monitored. This means that activity on a newly created file cannot be monitored reliably, and that a file descriptor per file in the hierarchy is required. inotify on the other hand allows a directory and its entries to be monitored at once. It introduces a new file descriptor type to which "watches" can be attached; a watch is a pseudo-file descriptor associated with a file or directory and a set of events to watch for. When a watched vnode is accessed, a description of the event is queued to the inotify descriptor, readable with read(2). Events for files in a watched directory include the file name. A watched vnode has its usecount bumped, so name cache entries originating from a watched directory are not evicted. Name cache entries are used to populate inotify events for files with a link in a watched directory. In particular, if a file is accessed with, say, read(2), an IN_ACCESS event will be generated for any watched hard link of the file. The inotify_add_watch_at() variant is included so that this functionality is available in capability mode; plain inotify_add_watch() is disallowed in capability mode. When a file in a nullfs mount is watched, the watch is attached to the lower vnode, such that accesses via either layer generate inotify events. Many thanks to Gleb Popov for testing this patch and finding lots of bugs. PR: 258010, 215011 Reviewed by: kib Tested by: arrowd MFC after: 3 months Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D50315 (cherry picked from commit f1f230439fa48581f40a57f095627f667a9713c3) share/man/man4/rights.4 | 10 +- sys/bsm/audit_kevents.h | 1 + sys/conf/files | 1 + sys/fs/nullfs/null_subr.c | 4 + sys/fs/nullfs/null_vnops.c | 29 +- sys/kern/kern_resource.c | 21 + sys/kern/subr_capability.c | 4 + sys/kern/sys_generic.c | 33 +- sys/kern/syscalls.master | 15 + sys/kern/vfs_cache.c | 59 +++ sys/kern/vfs_default.c | 17 + sys/kern/vfs_inotify.c (new) | 1004 ++++++++++++++++++++++++++++++++++++++++++ sys/kern/vfs_subr.c | 7 +- sys/kern/vfs_vnops.c | 3 +- sys/kern/vnode_if.src | 21 + sys/sys/caprights.h | 2 + sys/sys/capsicum.h | 8 +- sys/sys/file.h | 1 + sys/sys/inotify.h (new) | 146 ++++++ sys/sys/resourcevar.h | 4 + sys/sys/specialfd.h | 5 + sys/sys/user.h | 5 + sys/sys/vnode.h | 12 +- sys/tools/vnode_if.awk | 1 + 24 files changed, 1399 insertions(+), 14 deletions(-)
Thanks to all of those who worked on this.