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

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 08/22/05

  • Next message: Hajimu UMEMOTO: "Re: [CFR] reflect resolv.conf update to running application" 
    Date: Mon, 22 Aug 2005 08:16:45 -0700
To: Poul-Henning Kamp <phk@haven.freebsd.dk>

    On Sun, Aug 21, 2005 at 07:17:06PM +0200, Poul-Henning Kamp wrote:
    > In message <20050821115454.55441a64@Magellan.Leidinger.net>, Alexander Leidinger writes:
    > >On Sun, 21 Aug 2005 00:37:56 +0100 (BST)
    > >Robert Watson <rwatson@freebsd.org> wrote:
    > >
    > >> (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've always been very leery of
    > >> re-reading configuration files automatically based on a time-stamp, as
    > >> updates to files are not atomic at all.
    > >
    > >Can kqueue be used instead of polling?
    >
    > Programs writing resolv.conf should just this the right way:
    >
    > 1. Write new contents to temorary file.
    > 2. Rename temporary file to resolv.conf.

    The one issue with this is that we sortof support a read-only /etc with
    resolv.conf as a symlink to somewhere else. Short of following the
    symlink by hand in dhclient-script, you have to do the current cat
    trick. It should cause the file to be replaced in one write() though so
    I don't think the race exists (unless someone comes up with a dhclient
    config that generates a resolv.conf larger then 512-bytes).

    -- Brooks 

    -- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

  • Next message: Hajimu UMEMOTO: "Re: [CFR] reflect resolv.conf update to running application"