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

From: Doug Barton (dougb_at_FreeBSD.org)
Date: 08/27/05

  • Next message: Matthew N. Dodd: "Re: [CFR] reflect resolv.conf update to running application" 
    Date: Fri, 26 Aug 2005 19:07:49 -0700
To: Hajimu UMEMOTO <ume@FreeBSD.org>

    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
_______________________________________________
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: Matthew N. Dodd: "Re: [CFR] reflect resolv.conf update to running application"