Subject: Re: re-reading /etc/resolv.conf on change
To: Luke Mewburn <lukem@NetBSD.org>
From: John Hawkinson <jhawk@MIT.EDU>
List: tech-userlevel
Date: 01/01/2004 08:23:30
Luke Mewburn <lukem@NetBSD.org> wrote on Fri,  2 Jan 2004
at 00:16:03 +1100 in <20040101131603.GJ16022@mewburn.net>:


>   | 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. I'd also like to have a better understanding of its
>   | performance effects, especially on slow machines.
> 
> FWIW; the existing nsswitch code does this for every lookup
> (stat's /etc/nsswitch.conf to check for changes) and has done
> so since the code was imported over seven years ago, and
> no-ones complained about it.  I don't think this is a big issue;
> the kernel should be caching it.

Your point is well taken on the performance effect.

However, Andrew's point about semantic changes still holds -- in
some cases it is desirable to edit resolv.conf and expect
previously started applications to continue their behavior; an
option to preserve this does not seem too far-fetched to me.

--jhawk

> If it turns out to be an issue, we can setup a kqueue EVFILT_VNODE
> filter on the configuration files (nsswitch.conf, resolv.conf, ...)
> and on /etc if the files don't exist...