[ On Friday, January 2, 2004 at 17:00:23 (-0700), Bruce J.A. Nourish wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> Granted. But it _is_ an important, system wide, change in state.

No, not really.  It's only likely important to some long-running
programs, and if it is important to them then it's likely they'll care
about other config files as well and thus likely they'll already support
SIGHUP or a similar mechanism.

> > This is only a userland to userland issue.  SIGHUP is your friend.
> 
> SIGHUP is a blunt weapon: a process that recieves SIGHUP has no idea
> what changed until it repolls all of it's configuration data.

Of course -- it's up to the application to figure out what to do when
it's been told there may have been some change of state in its runtime
environment.  As a generic mechanism anything more specific would be too
inflexible -- though of course an application is free to use any other
mechanism.  I say "SIGHUP is your friend" because in 99.9% of the
situations we've talked about it's already in use for this very purpose.

> Also, most interactive processes do not respond that way to SIGHUP at
> all: they quit instead! I believe this is the historically correct way 
> to behave.

Well of course.  But you're focusing on a detail that's not fixed in
stone and which is merely an enabler, not the key mechanism.

First off note too that "interactive" processes are not (normally) "long
running" processes, and are not likely started from /etc/rc.

SIGHUP is simply a common example of how existing _daemon_ processes are
signalled to re-check and perhaps re-load their configs.  What I've
proposed allows for any current or future signalling mechanism, and
allows for either the total generality of SIGHUP or something as
specific as writing "re-read /etc/resolv.conf now!" down a control
socket or any mix inbetween, and allows for handling any number of
currently running daemons.

Any interactive process worth its salt would also be able to make
trivial use of the exact same mechanism I've proposed for reloading
/etc/resolv.conf (or indeed choosing to use some alternate config file).
An interactive process would of course, by definition, have some
interactive way of signalling that the state of its runtime environment
might need reexamining.

Further note the mechanisms I've proposed also makes it trivial for any
application, daemon or interactive, to choose to periodically stat() the
resolv.conf file they're using.  They also allow any application to
choose to reload it at any time it feels like it (e.g. every second,
every minute, or every time through their main event loop).

What you're proposing is _MUCH_ more complex and far more error prone.

I think we already have all the tools we could possibly ever need and
them some to signal programs and control their behaviour.  All we're
missing are a couple of trivial little hooks to add controls to the
resolver library that should probably have been there right from the
very beginning of its existance.  The key point I've been trying to make
all along here is that it is wrong to try to hide the checking and
reloading in the library and it's doubly wrong to compound that error by
using an environment variable to override the default file.

The BIND resolver library has always (well since 1994 anyway) allowed
res_init() to be called by an application at any time and doing so will
force a re-load _PATH_RESCONF.  Someone probably should have mentioned
this almost obvious thing long before now in this thread, but it I don't
think it has been said before now.  I've been assuming everyone knew
this would work (and if they didn't they'd have read the source and
discovered it anyway).  I hadn't said anything this explicit before
simply because I was also thinking of the secondary feature of choosing
an alternate configuration file.

I.e. we already have one of the hooks I speak of, and it's as good as
"standard", but not explicitly documented as serving this exact purpose
(though neither does the documentation say it can't be used for this
purpose).  All we're really missing is the secondary feature of allowing
an application to override the default filename IFF it so chooses.

-- 
						Greg A. Woods

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