Re: [CFR] reflect resolv.conf update to running application

From: Hajimu UMEMOTO (ume_at_freebsd.org)
Date: 08/21/05

  • Next message: Alexander Leidinger: "Re: [CFR] reflect resolv.conf update to running application" 
    Date: Sun, 21 Aug 2005 14:05:15 +0900
To: Peter Jeremy <PeterJeremy@optushome.com.au>

    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/
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Alexander Leidinger: "Re: [CFR] reflect resolv.conf update to running application"