> Subject: Re: re-reading /etc/resolv.conf on change
.
> but their current code doesn't reload resolv.conf. Worst, resolv.conf is 
> hidden in the resolver library code.

I don't see any problem here.  We're talking: (a) about a _new_ feature
(even though it's an old problem); and (b) about a simple way of optionally
"unhiding" the resolver configuration mechanism to at least some level.

> Also, signals don't marry well with threads. But that's a different story.

It's an irrelevant story.  All the daemons that already reload their
configuration files on receipt of SIGHUP have already dealt with this
problem satisfactorily if indeed they ever had to worry about it.  The
rest have invented new mechanisms (e.g. the socket used by named), and
what I'm proposing overall works with _any_ and _every_ possible
mechanism.

> Who would run /etc/rc reload?

dhclient-script, for example.

Or any other mechanism that already runs to affect changes in network
interfaces, routing, or what have you (e.g. pppd, etc.).

Remember -- we're only talking about a tiny little enhancement to things
that are already implemented and working almost perfectly (save for the
fact that some programs don't yet have any way to tell the resolver code
to re-load its configuration).

Note also that "/etc/rc reload" is merely another minor enhancement to
make everything generic.  We already have "/etc/rc.d/* reload" and it
already works just fine for almost everything except /etc/resolv.conf.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>