Subject: Re: re-reading /etc/resolv.conf on change
To: Simon J. Gerraty <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/31/2003 16:06:57
On Tue, Dec 30, 2003 at 12:18:39AM -0800, Simon J. Gerraty wrote:
> >> Also, does this code work correctly if resolv.conf is a symlink?
> >open() will follow the symlink, so the kevent filter will watch the target of
> >the symlink, not the symlink itself. I can see 2 ways to loose with this:
> >- if the symlink doens't point to a real file, and points outside of /etc/
> > in this case, open() will fail, and the kevent will be set on /etc.
> > Then we can recreate a file as the symlink's target, but the resolver won't
> > notice it.
> >- if we change the symlink to point to another file.
> Is kqueue the right solution then? How bad would it be to simply
> open resolv.conf and fstat it? You could record the mtime as well as
> the time you last looked and avoid doing so more than once in
> some window. That would be bog simple and probably not too expensive.
To achieve the same feature as kqueue (detect mv or rm), we need stat(),
not fstat(). This means a NAMEI lookup for each call.
I don't know if it's considered to be too expensive to do it for each
resolver call (but I gess we could as well reread the resolv.conf file
I don't think doing the check once per time window is good enouth,
because even if the window is small you may run in a DNS timeout, which is
quite long. The changes have to be picked up immediatly.
> You could also invalidate the handle on certain DNS failures to speed
> things up even with a bigger cycle time for re-checking...
This would add yet more changes to the resolver :)
Also we need to have the change piked up immediatly, instead of
waiting for a DNS timeout.
Manuel Bouyer <firstname.lastname@example.org>
NetBSD: 23 ans d'experience feront toujours la difference