Re: configuration files

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Fri, 12 Dec 2003 17:35:37 -0500
Dan Melomedman <dan@xxxxxxxxxxx> wrote:

> Chris Pressey wrote:
> > Well, then I have to wonder why so many seemingly redundant
> > processes are needed.  Using messages instead of signals, couldn't
> > process 117 wait for any of it's children to send it an 'exit'
> > message, then restart just that child?
> > 
> > -Chris
> 
> Because redundancy and simplicity are the features. Otherwise you have
> the funnel design which needs more complexity and if such a supervisor
> is busted, then it affects all your services, not just one.

Yes, it's definately cornered the simplicity market.

But I keep thinking, how complex could a service monitor possibly be
anyway?  It's not like it's an XML parser :)

T'm no fan of select() either, and I'm sure each of those
sub-supervisors doesn't take up much memory, but I also keep thinking
that they wouldn't have to exist at all if the super-supervisor could do
just a little more work.

There's also this to consider - what happens when a service which has
other services depend on it, dies?  Do you kill & restart the dependent
services automatically?  Depending on the type of service, you may or
may not have to.  runit's support for service dependencies seems rather
manual (based on skimming http://smarden.org/runit/dependencies.html)
compared to RCNG's, which seems more automatic.

If dependent services should be restarted automatically, the supervisor
will have to be more complex anyway - having individual sub-supervisors
(which would have to be aware of the dependencies, and which would have
to be able to kill & restart services that aren't "their own") seems to
me to be no simpler than having a single supervisor that "funnels" exit
messages from multiple children.  I could be wrong, though, of course.

This brings up an interesting question for Matt - what kind of support
will there be for waiting for messages from multiple senders?  Would one
create a single port and have multiple senders direct their messages to
that one port, then wait on that port for the next available message
from anyone... or will it be possible to wait on multiple ports?

-Chris