On 24/10/2012 18:59, Dan Williams wrote:
On Tue, 2012-10-23 at 20:42 +0100, Simon Kelley wrote:
On 23/10/12 20:21, Gene Czarcinski wrote:
It would be useful to libvirt if dnsmasq would reread the configuration
file and/or the files in the configuration directory upon demand (via
SIG<something>) as is done for some other files.
Right now, when minor changes are made to a network configuration, it is
necessary to restart dnsmasq to get those changes adopted.
Is this a possibility this could be done or is this one of those things
that yes, it could be done, but it would require rewriting most of
dnsmasq. What types of changes might be accommodated? What if these
changeable definitions were put into a special configuration file?
Example: v6 or v6 dhcp-range.
Example of something that would unlikely be possible: interface=
The most difficult problem is that dnsmasq throws away root permissions
after start-up, so re-reading the configuration is impossible if acting
on the new configuration involves anything that needs root (for
instance, binding sockets to ports <1024 or opening the lease file.)
The philosophy is that things that would be really useful to change,
without restarting dnsmasq, and certainly don't need root, are re-read
on SIGHUP. That's dhcp-host information and dhcp-option information in
special configuration files, /etc/hosts and /etc/ethers, and possibly
/etc/resolv.conf, if it's not being polled anyway.
For anything else, restarting dnsmasq is a pain-free operation anyway:
there's very little state and nothing important is lost over a reboot.
One problem we ran into with NM, and why I posted the patch for the new
D-Bus interface call, was that updated DNS configuration is *not*
re-read on HUP. That means that whenever we change nameservers as a
result of DHCP renewal, connection of a VPN, or some other thing that
updates DNS, we need to either (a) use the D-Bus interface or (b)
respawn dnsmasq. Unfortunately there's a small window when respawning
dnsmasq where name queries could get lost or prematurely terminated, and
that's actually been a problem in the real world. In these cases we're
running dnsmasq as a local caching nameserver, so
re-reading /etc/resolv.conf would only ever return 127.0.0.1 and thus
that part isn't relevant.
Obviously if we're using D-Bus now this isn't a problem, but might be
worthwhile to re-read DNS server/domain info on HUP to for other users.
Dan
Is the answer then to always use dbus? Openresolv I think uses dbus in
this way when reloading data due to interface changes - is it not
handling things in the desired way? If so could you use it's technique?
http://roy.marples.name/projects/openresolv
Cheers
Ed W
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
