Subject: Re: re-reading /etc/resolv.conf on change
To: Luke Mewburn <lukem@NetBSD.org>
From: John Hawkinson <jhawk@MIT.EDU>
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.
> 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...