[ On Thursday, January 1, 2004 at 21:51:42 (+0100), mouss wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> Wouldn't a db based mechanism suitable here? This would require 
> generating the db files if the config files are updated, but this may be 
>   done by a standalone daemon which may implement a kqueue for all 
> possible files. And we already use db files for passwd stuff, so it's 
> not a completely new framework.

You want to use a database to send a binary flag or two!?!?!?!?

> > We already have such mechanisms, although they are a bit, well OK a lot
> > more generic than you outline above:  SIGCONT and SIGHUP.  :-)
> 
> signals assume a sig handler in the program code or in libc.

Of course.  but not in libc.

> Since we 
> can't rewrite all progs

we don't need to -- most already have appropriate reload support since
most long-running programs that use the DNS also have their own
configuration files to keep track of.

> libc would be the place.

Definitely _not_!

> But then we need a new 
> signal, to make sure it's not used by the program.

SIGHUP is already almost universally recognized as the "reload" trigger
for long-running programs.

However arbitrary programs won't be sent a SIGHUP, and even all daemons
wouldn't be sent a SIGHUP -- with the use of a proper "/etc/rc reload"
mechanism then a program will only be told to reload its config files if
it needs to know, and it'll always be told in the way it expects to be
told.  SIGHUP is only the default for the rc.d "reload" operation --
anything is possible, but "/etc/rc reload" makes it all very generic
from the point of view of those services which need to invoke the trigger.

> Sure but requiring the user to run a program after he updates a config 
> file should be last resort.

Who said anything about "the user"?!?!?!?

We're talking about "userland" here, not (just) end-user initiated
actions.

The "Unix Way" is to implement these sorts of things in userland,
i.e. by way of some program that runs out in userland, not in the
kernel.  The kernel simply provides the hooks for sending signals.

Witness "dhclient" -- which in fact would in many cases be the very
program responsible for triggering the actions we're talking about after
it edits /etc/resolv.conf -- it is a userland program responsible for
doing network discovery and interface address changes, etc.  The kernel
certainly doesn't implement the DHCP client.

-- 
						Greg A. Woods

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