It turned out this problem is caused by something our corporate processes deployed on our managed machines. In my case, a very high number of watches is caused by osqueryd. That is deployed with some our custom rules. In our case, it is run by orbit, part of fleetdm [1][2] solution of "protecting" large fleet of corporate users. I doubt common users here have experience with similar stuff. Likely to be seen by corporations workers, who often do not use Linux unfortunately.

In any case kde-inotify-survey is a great tool for analysis where are used notify sockets and watches allocated. When this problem was active, I had "watchPercent": 100 when started it with sudo. In my case the warning is not printed, because dnsmasq user has separate number of watches and is able to watch it successfully. I am not sure if it makes sense to try watching only after dropping privileged user rights. It might create some regressions. My retry adds a bit extra code, but should be the safest option available.

1. https://fleetdm.com/
2. https://github.com/fleetdm/fleet

On 11/02/2026 22:12, Petr Menšík wrote:

Hello!

I have recently started to have issues when starting libvirt, which starts dnsmasq for DHCP and local machine DNS.

I have started seeing inotify sockets failures in multiple packages. But the thing is, I cannot start libvirt network now. I think inotify socket should not usually be cause of fatal error.

sudo virsh net-start default ends always with this failure. It usually helps to reboot the machine. I am not sure how to identify inotify usage on my machine.

Strange is this seems to be problem only of root user.

$ sudo inotifywatch /etc/resolv.conf
Establishing watches...
Failed to watch /etc/resolv.conf; upper limit on inotify watches reached!

$ inotifywatch /etc/resolv.conf
Establishing watches...
Finished establishing watches, now collecting statistics.

Strange is number of user watches should be somehow high:

$ cat /proc/sys/fs/inotify/max_user_watches
511013

So I started thinking, should be a failure to initialize inotify socket a fatal error? It seems to me warning would be all right.

dnsmasq supports running even without inotify support. I have created a modification to run even in that case, only emit warning. I think failure to observe resolv.conf changes should not be a fatal error, unless requested somehow more explicitly.

In attached change, I retry inotify creation with dropped privileges. It might help in my case and even for others. First time it fails only silently, because logging is not yet prepared. Only second time it also logs warnings.

Minor change is making more obvious difference between main inotify socket and inotify watch creation error.

Regards,
Petr

--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss