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

[Petr Menšík]

Oh, okay, those forking TCP processes are a problem of its own, but 
would require a significant rework of existing logic. More below.

On 20/02/2026 17:18, Simon Kelley wrote:
> A problem with this patch is the error handling. You can't call die() 
> in the second call to  inotify_dnsmasq_init() because the daemon has 
> forked into the background by then. It's necessary to do the whole 
> fatal_event() stuff to make sure that the original process exits with 
> a suitable error code. Some of the errors have turned into warnings, 
> but there are still errors in there that should be fatal.

Can you give an example, please? If the /etc/resolv.conf points to 
localhost, such as in my case, there is no reason for using watch on it. 
Nor fail hard because of it failed to allocate. Unless I am able to 
specify what I want, it should not be fatal error IMO.

What is the reason for inotify usage in TCP forks anyway? They are never 
long-living, after they handle the TCP socket request, they always die, 
right? Dnsmasq does not support pipelining of multiple requests and 
idling with TCP sockets waiting for new queries, right? I think it 
should be okay in that case to wait for new TCP fork again and let it 
use whatever it already had. Eventually main process might send HUP from 
main process, since it has the pid of child.

Can it even use the inotify from worker forks? Should it close inotifyfd 
right after fork? I am not sure whether it even allocates additional 
socket or not.

>
> Given that this patch makes dnsmasq change its behaviour from what's 
> configured, sometimes, and with only a log warning, do you still think 
> it's worth doing now you've found the root cause?
>
>
> Simon.

Yes! Because I know the cause, but there is not simple workaround in 
dnsmasq. I think it could be used to DoS the system by leaking inotify 
sockets intentionally. I have never instructed dnsmasq to insist on 
inotify watch, nor I can configure it optional nor disabled anywhere. 
Because some platforms do not even have inotify support, I think we can 
handle failed initialization the same way.

I expect adding new option for fatal exit on inotify watch failure is 
not what you would prefer. Is it? Should we add new option for inotify 
instead?

inotify=required # fail hard
inotify=optional # try to use inotify, but continue if it fails, 
proposed new default?
inotify=disabled # do not even attempt to use inotify, even if the 
platform has it and no-resolv is unused

What is your preference?

Cheers,
Petr

>
> On 11.02.2026 21:12, Petr Menšík via Dnsmasq-discuss 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/20260304/0b458c5d/attachment-0001.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/20260304/0b458c5d/attachment-0001.sig>