Subject: Re: re-reading /etc/resolv.conf on change
To: Manuel Bouyer <firstname.lastname@example.org>
From: Simon J. Gerraty <email@example.com>
Date: 01/01/2004 09:45:33
On Wed, 31 Dec 2003 16:06:57 +0100, Manuel Bouyer writes:
>> 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.
No, if you open the file - you are guaranteed that you have read what
it points to. No need to worry about wether it is a symlink, or if
the link moved etc. fstat is then ok - just to retrieve the mtime,
and other bits that could let to check if the file is the same as the
last one you parsed.
>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
It would be too expensive for each call I think - but also
unnecessary. Once every N seconds would be plenty. If you only do a
DNS lookup every few minutes then you'll do the check each call, but
for someone doing lookups many times a second you don't want that
>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.
Why? How often do you change resolv.conf? Even for laptop users we
are talking hours b/w changes - for most users more like months or
years. In that timeframe an occasional DNS timeout is noise.
The kqueue solution described sounds way too complex for my liking.
>> 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.
No - see above.