>> > 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
>> /etc/sites/foo/resolv.conf
>> 
>> 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

or...this:

	# 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);
	fstat(fd, &st);
	<compare new st_dev/st_ino/st_size/st_mtime/st_ctime with
	recorded st_dev/st_ino/st_size/st_mtime/st_ctime>

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" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."