Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: mouss <firstname.lastname@example.org>
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.