Date: Sun, 21 Aug 2005 14:05:15 +0900 From: Hajimu UMEMOTO <ume@freebsd.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: [CFR] reflect resolv.conf update to running application Message-ID: <ygeacjbyj5g.wl%ume@mahoroba.org> In-Reply-To: <20050821040454.GP13959@cirb503493.alcatel.com.au> References: <ygefyt4yiaz.wl%ume@mahoroba.org> <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
>>>>> On Sun, 21 Aug 2005 14:04:54 +1000
>>>>> Peter Jeremy <PeterJeremy@optushome.com.au> said:
PeterJeremy> Overall, I think that having applications see changes to /etc/resolv.conf
PeterJeremy> is a good idea.
Thanks.
PeterJeremy> On Sun, 2005-Aug-21 00:37:56 +0100, Robert Watson wrote:
>(1) Has anyone characterized the significant of the cost of doing a stat()
> for every DNS lookup for a significant workload? Does it matter?
PeterJeremy> I wrote a short program to run stat("/etc/resolv.conf") in a loop.
PeterJeremy> On a P-233 running 4.9, I got about 45000 iterations/sec.
PeterJeremy> On a P-120 running 5.4, I got about 10500 iterations/sec.
PeterJeremy> I don't think this matters - especially compared to the overheads
PeterJeremy> involved in sending and receiving the DNS UDP packets. If you are
PeterJeremy> stating the same name frequently, it will be in the name cache so
PeterJeremy> the name lookups are fairly cheap.
Yes, I think a cost for stat() is considerably low than actuall DNS
lookup.
>(2) By reading the configuration file more frequently and more quickly
> after a change, we increase the chances of a race condition in which
> the resolve reads a partially written resolv.conf file during an
> update. Does this happen in practice?
I had care to don't update during the critical path. For example, I
didn't change to use _res_init() in res_send().
I have been using this patch for myself about 3 months without any
problem.
PeterJeremy> This could be more of an issue, though I have no idea whether it
PeterJeremy> really is. The easy work-around is to avoid updates. Instead create
PeterJeremy> /etc/resolv.conf.tmp and rename it.
Yup, I forgot to mention. Our dhclient updates resolv.conf frequently
even when it is not changed. I think it is redundant, and I applied
following patch:
Index: sbin/dhclient/dhclient-script
diff -u sbin/dhclient/dhclient-script.orig sbin/dhclient/dhclient-script
--- sbin/dhclient/dhclient-script.orig Fri Jun 10 12:41:18 2005
+++ sbin/dhclient/dhclient-script Wed Jun 29 06:13:14 2005
@@ -152,6 +152,11 @@
cat /etc/resolv.conf.tail >>/etc/resolv.conf.std
fi
+ if diff /etc/resolv.conf.std /etc/resolv.conf >/dev/null 2>&1; then
+ rm -f /etc/resolv.conf.std
+ return 0
+ fi
+
# In case (e.g. during OpenBSD installs) /etc/resolv.conf
# is a symbolic link, take care to preserve the link and write
# the new data in the correct location.
I wish to commit this, too.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ygeacjbyj5g.wl%ume>