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.