dnsmasq does not respect/watch '/etc/hosts' updates

The manpage talks about:

 -T, --local-ttl=<time>
              When replying with information from /etc/hosts or the DHCP leases file dnsmasq by default sets the time-to-live field to zero,
              meaning that the requestor should not itself cache the information. This is the correct thing to do in almost all situations.
              This option allows a time-to-live (in seconds) to be given for these replies. This will reduce the load on the server at the
              expense of clients using stale data under some circumstances.

it's actually being run as:

  /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --cache-size=0 --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf

with '/var/run/nm-dns-dnsmasq.conf' containing just:

  server=10.0.0.5

(ie, the upstream DNS server).

The manpage also mentions:

       --clear-on-reload
              Whenever /etc/resolv.conf is re-read, clear the DNS cache. This is useful when new nameservers may have different data than
              that held in cache.

but this is for 'resolve.conf'. This corresponds to the enum OPT_RELOAD and ultimately gets used as:

           if (option_bool(OPT_RELOAD) && do_reload)
            clear_cache_and_reload(now);

Had a reply from Simon Kelly (upstream). The worry is about race conditions and reading /etc/hosts or resolv.conf after the 'mtime' has been changed, but before the file has been completely written out (dnsmasq already tries to backoff and schedule a re-read a couple of seconds late if it finds an incomplete file). The preferred solution is for the process modifying the appropriate file to manually send:

  sudo killall -HUP dnsmasq

to the process.

Currently (on Ubuntu) dnsmasq is run as uid='nobody', so these needs elevated privileges (which are needed anyway for editing those files). This is okay for a human, but is less automatic than the previous situation where /etc/hosts was being watched.

I'm marking this bug fix released for the specific case of Network Manager.

Since last week we now use --no-hosts with the dnsmasq spawned by Network Manager, /etc/hosts resolving is now exclusively done by the libc/nss resolver and dnsmasq only handles the actual DNS resolving.

(Workaround was introduced to Network Manager).

In the mean-time upstream are now looking at inotify support for dnsmasq-2.61 to reduce the residual polling overhead in the longer-term (will miss 2.60 as that's nearly out).