[CFR] reflect resolv.conf update to running application

Hajimu UMEMOTO ume at FreeBSD.org
Thu Sep 8 08:31:43 PDT 2005


>>>>> On Fri, 26 Aug 2005 19:07:49 -0700
>>>>> Doug Barton <dougb at FreeBSD.org> said:

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

Yup, there might be no benefit for non-mobile users.  However, I
believe it is still useful for mobile users.  So, I changed to look a
kernel environment variable.  If resolver_reread_conf is set, the
feature will be activated.  You can find my new patches from:


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

Since a resolver is in each applications, I think it is hard to send a
HUP signal to resolvers without having a daemon which does DNS query.


Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org

More information about the freebsd-arch mailing list