Subject: Re: re-reading /etc/resolv.conf on change
To: Manuel Bouyer <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 12/31/2003 16:33:25
>> > How about stat'ing /etc/resolv.conf, opening the kqueue on it *and* /etc
>> > always and checking the stat values on every kqueue event?
>> > Seems like that way all failure modes discussed so far could be easily
>> > detected.
>> resolv.conf is symlinked to /etc/sites/foo/resolv.conf
>> someone does an mv /etc/sites/foo/resolv.conf to
>> /etc/sites/foo/resolv.conf.new and then creates a new
>> I don't think that would be detected.
>It would with kqueue, because it will monitor /etc/sites/foo/resolv.conf (open
>follows the symlink) and a rename is a one of the events monitored.
fine, then i'll do this:
# mv /etc/sites/foo /etc/sites/bar
# mv /etc/sites/baz /etc/sites/foo
# mount -t null /etc/sites/bar /etc/sites/foo
kqueue can't catch that...can it?
i think that for whatever you can decide to watch, i can invent a
scheme that will "accidentally" bypass it. we either need to decide
what the basic requirements are, or decide that doing:
fd = open("/etc/resolv.conf", O_RDONLY);
<compare new st_dev/st_ino/st_size/st_mtime/st_ctime with
or something like that. and then smack a sticker on it saying that we
done our best.
personally, i *like* that i can stuff something into /etc/resolv.conf,
start one thing, and then restuff /etc/resolv.conf for everything
else. if the resolver would look at environment variables as well as
/etc/resolv.conf (for a path or nameservers or something), then that'd
be good too, but that's not on the menu. we don't even consider
cooking that here.
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."