[CFR] reflect resolv.conf update to running application

Doug Barton dougb at FreeBSD.org
Sat Aug 27 02:07:53 GMT 2005


I've been following this thread with interest, and while I applaud the 
effort that's gone into this I'm not sure it has a very high cost/benefit 
ratio for the majority of FreeBSD systems. This would potentially be useful 
for mobile systems that will often be moved into different networks, but 
frankly I don't see a benefit for the vast majority of systems that will 
have the same resolv.conf file for weeks, months, or years. I'm also 
thinking of various types of high performance systems that actually do 
thousands of DNS queries a minute. While a stat() call in the resolver path 
for every query might not be noticeable on a "typical" system, they would 
add up on systems that are already being stressed.

Personally, I would much rather we add some method of "HUPing" the resolver 
to re-read resolv.conf. That way we could add that command to 
dhclient-script and send it whenever the resolv.conf file is actually 
changed. This could also be used by sysadmins for typically "static" systems 
instead of having to restart services on those systems.

IF we go the route of dynamically re-reading the conf file (and I hope we 
don't), then at minimum I think that the stat() and kqueue methods should be 
benchmarked with as close to real world loads as possible.

hth,

Doug


-- 

     This .signature sanitized for your protection



More information about the freebsd-arch mailing list