Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/01/2004 00:21:42
[ On Wednesday, December 31, 2003 at 13:43:23 (-0500), John Hawkinson wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
> Jason Thorpe <email@example.com> wrote on Wed, 31 Dec 2003
> at 09:33:55 -0800 in <81FB27EB-3BB7-11D8-A1C7-000A957650EC@wasabisystems.com>:
> > On Dec 31, 2003, at 7:10 AM, Manuel Bouyer wrote:
> > >
> > > OK, would a message to syslog be acceptable ?
> > I don't think any message is necessary.
> I think a message should appear when RES_OPTIONS=debug is set.
I would agree. Also there are a bunch of #ifdef DEBUG wrappers around
really useful debug messages in the resolver code that should probably
be changed to #ifndef NDEBUG, or perhaps changed to some new unique macro
that's defined by default (which is what I do: CPPFLAGS+=-DRESOLVDEBUG).
Any new message(s) could/should be similarly wrapped.
> I'm a bit puzzled at all the clamoring for this change.
Me too! ;-)
> Why don't
> people simply run local caching resolvers? It's far better on the
> network (though increases the memory footprint some).
It wouldn't even be difficult to have dhclient or whatever modify the
forwarders settings in /etc/named.conf. :-)
> If we're actually going to propose a filesystem access on every
> nameservice check (i.e. fstat() or lstat()), I think that is not an
> appropriate change if it is mandatory, and it should be controlled by
> an option.
Personally though I'd rather have a hook that an application could use
to force a re-read. Long-running network daemons could then simply call
that hook at the same time they re-read their own configs on SIGHUP,
something most any daemon of interest will already support, and if not
then it should.
> I'd also like to have a better understanding of its
> performance effects, especially on slow machines.
That's for sure!
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>