(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).
** Package changed: dnsmasq (Ubuntu) => network-manager (Ubuntu)
--
You
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.
** Changed in: dn
** Changed in: dnsmasq (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/946754
Title:
dnsmasq does not respect/watch '/etc/hosts' updates
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
The manpage talks about:
-T, --local-ttl=
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 d
