[Dnsmasq-discuss] rereading configuration files

Dan Williams dcbw at redhat.com
Wed Oct 24 18:59:47 BST 2012


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




More information about the Dnsmasq-discuss mailing list