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
then :)
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 <bouyer@antioche.eu.org>
     NetBSD: 23 ans d'experience feront toujours la difference
--