Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: mouss <>
List: tech-userlevel
Date: 01/01/2004 21:51:42
Greg A. Woods wrote:
> [ On Wednesday, December 31, 2003 at 17:19:18 (-0500), Perry E. Metzger wrote: ]
>>Subject: Re: re-reading /etc/resolv.conf on change
>>Another possibility -- maybe we are looking at this wrong? There are a
>>variety of conditions we might want to inform programs of ("you've
>>just been awakened after a deep sleep", "the network addresses have
>>all changed", "your resolv.conf is different"), and perhaps we should
>>come up with a more general mechanism for telling programs about such

yes, a "unified" notification framework...

Wouldn't a db based mechanism suitable here? This would require 
generating the db files if the config files are updated, but this may be 
  done by a standalone daemon which may implement a kqueue for all 
possible files. And we already use db files for passwd stuff, so it's 
not a completely new framework.

> We already have such mechanisms, although they are a bit, well OK a lot
> more generic than you outline above:  SIGCONT and SIGHUP.  :-)

signals assume a sig handler in the program code or in libc. Since we 
can't rewrite all progs, libc would be the place. But then we need a new 
signal, to make sure it's not used by the program.

> However in my experience they've been quite sufficient for these
> purposes.  I think any finer-grained mechanism inbetween SIGHUP and
> kqueue events would be simply too specialized to be worthwhile.
>>Then, if you alter resolv.conf, run a program announcing "I've altered
>>resolv.conf" to the world and all will be well! :)
> Adding support for a "reload" parameter to /etc/rc would be trivial.
> (and doing so wouldn't even assume SIGHUP support -- our rc.d scripts
> are already flexible enough to support any mechanism for communicating
> with a running daemon)

Sure but requiring the user to run a program after he updates a config 
file should be last resort. Ideally, things should be transparent. This 
would not only make users happier, but would also avoid nasty bugs when 
some software updates these files and "forgets" to run the updater.