[Dnsmasq-discuss] [PATCH] dnsmasq: failed to create inotify for /etc/resolv.conf: No space left on device

[Petr Menšík]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 12641 bytes
Desc: OpenPGP public key
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260218/2f27a705/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260218/2f27a705/attachment.sig>