[Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?

Simon Kelley simon at thekelleys.org.uk
Thu Aug 12 15:04:37 UTC 2021

On 11/08/2021 00:25, Ed W wrote:
> On 10/08/2021 23:12, Simon Kelley wrote:
>> On 08/08/2021 14:02, Ed W wrote:
>>> On 19/07/2021 18:52, Ed W wrote:
>>>> Hi, around 2.82 someone posted a little patch to import the config files in dictionary order, which
>>>> is very useful for situations where you have overlapping definitions. I'm using an addn-hosts stanza
>>>> pointing to a directory and files currently import in a somewhat random order (suppose inode
>>>> order?), which can lead to unexpected reverse host definitions in some cases
>>>> Could we have a dictionary order import for add-hosts files please?
>>>> Ed W
>>> Hi, I have developed the attached patch without really being sure that this is the best approach. I
>>> would be grateful for some feedback. I have used scandir without understanding if this is portable
>>> across systems that we support with dnsmasq. Also I am trying to copy the existing coding style, but
>>> surely I have failed.
>> I'll look in more detail soon, but this certainly looks like the right
>> way to go.
>>> I'm also unclear that it still works as advertised in the case that I don't have inotify enabled?
>>> Any help?
>> Since the whole point of the inotify stuff is that individual files get
>> read as they change, imposing or relying on a particular order doesn't
>> make much sense. I'd therefore not make any changes to inotify.c.
>> The man page then needs to note that --dhcp-hostsdir --dhcp-optsdir and
>> --hostsdir DON'T offer any ordering of files read, but
>> --dhcp-hostsfile --dhcp-optsfile and --addn-hosts with directory
>> arguments DO.
> Aha, then I might have gone off the rails here then...
> It's the changes in inotify.c which affect my --addn-hosts directives? I left the top part of the
> patch to option.c in there as it seemed like it probably affected (hostsdir?), and seemed useful yet
> without any real cost?

That's not my understanding.

--dhcp-hostsfile --dhcp-optsfile and --addn-hosts have nothing to do
with inotify. The argument to any of them can be a directory, rather a
file, and then all the files in the directory get read. Reading these
files ONLY happens at start-up and when SIGHUP is received, at which
times _all_ the files get read. It makes sense to define the order of
reading these files within a directory. When SIGHUP is received, the old
data from the files in discarded, and they are all re-read.

--dhcp-hostsdir --dhcp-optsdir and --hostsdir work in much the same way
as when the first three options are given a directory; the files are
read at start-up and when SIGHUP is received. BUT any file which is
modified or created gets read asynchronously, without needing SIGHUP to
be sent. Note that the old data from the files is not discarded when
this is done: if a file gets modified, then it gets re-read but data
from the previous version of the file is not deleted. This means that
this facility is useful for adding hosts to the configuration without
the upheaval of a full SIGHUP re-read. Anytime you want to delete stuff,
SIGHUP is still needed.

Given the above, defining the order in which files in those directories
are read is a bit pointless: sure, you can define and order for startup
and SIGHUP, but then as soon as file is touched or added, the order
depends on that.

If you're using --addn-hosts, then the inotify code isn't affecting what
you're doing: you must be sending SIGHUP to re-read any changes to the

The inotify code can be omitted entirely and --addn-hosts will still
work, but --dhcp-hostsdir --dhcp-optsdir and --hostsdir options will be

Given that, I propose to take your patch to expand_filelist(), which
will define the order for --dhcp-hostsfile --dhcp-optsfile and
--addn-hosts when they take directories, but not the changes in
inotify.c, which are not needed for that.



> Could it be that when inotify fires that it pulls in all files in --addn-hosts? In which case the
> dictionary order functions, even though we have inotify?
> Ed W

More information about the Dnsmasq-discuss mailing list