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

[Simon Kelley]

On 04.03.2026 14:51, Petr Menšík via Dnsmasq-discuss wrote:
> 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.
> 

This has nothing to do with TCP worker forks, it's to do with creating a 
daemon process. This has various steps; changing uid, and capabilities 
etc, but it also involves  a fork(). The child process continues as the 
daemon and the original process exits.


In dnsmasq initialisation happens in two stages. The first stage goes to 
around line 639 in src/dnsmasq.c and does most of the work. It runs as 
root and whatever privileges the process inherited. Fatal errors result 
in a call to die(), which prints to stderr and maybe logs the same, then 
calls exit() with a non-zero return code.

The code 610-649 forks the new process, and the original process blocks, 
waiting to read from a pipe which the original and new processes share. 
 From that point on, calling die() is not allowed, as that will only 
exit the new process and the error won't be propagated back to the 
original process.

A fatal error is still allowed, but it has to be signalled by sending a 
report via the pipe to the original process and then calling _exit(0) 
The original process logs/prints the error and then exits with a 
non-zero return code. An example of this is

  send_event(err_pipe[1], EVENT_PIDFILE, errno, daemon->runfile);
  _exit(0);

at line 706.

After the fork() The intialisation continues to the second stage, and 
amongst lots of other stuff, the uid is changed and capabilities are 
dropped. This section uses the send_event() method to handle any fatal 
errors. It ends at line 1096, where the pipe gets closed by the daemon 
process. This unblocks the original process which exits with a zero 
return code. From that point on, fatal errors are not allowed; the code 
will never exit and does everything it can to continue running.


My patch moves the inotify initialisation from the first stage of 
initialisation to the second stage, so that it happens after the uid has 
changed. The intention is that the notify watches therefore get 
accounted for against the "dnsmasq" user and not root, The original 
problem you saw, where a different process has exhausted the the quota 
of root watches and caused dnsmasq to fail and die, should be solved by 
that. The move to the second stage init is needed because that is where 
setuid() gets called. Moving to the second stage init means that all the 
calls to die() in the inotify code have to be changed to use the 
send_event() method of posting the fatal error, which is the bulk of my 
patch.

I think that this change fixes the problem you saw, and makes the code 
behave in a more sane way, since it will no longer create inotify 
watches as root on files/directories which it can't access after 
changing uid.


Your patch is rather more complex, and maybe needlessly complex. It is 
also incorrect since it calls   inotify_dnsmasq_init() from both first 
and second stage initialisation, which still calls die() under some 
conditions, which is forbidden during  second stage init.



I hope that makes sense. It's not trivial!


Cheers,

Simon.


>>
>> 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
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss