Paralell startup

[Roberto Peon]

On Wednesday 20 October 2004 05:09 pm, Jeff Spaleta wrote:
> On Wed, 20 Oct 2004 16:39:07 -0400, Roberto Peon <grmoc at yahoo.com> wrote:
> > How would falling back to serial boot help?
> >
> > Not launching the services whose dependancies are not satisfied seems
> > like a good idea to me. It is better than the current, try it anyway, and
> > see it fail (sometimes spectacularly).
>
> Uhm... i think you are mixing several different technical problems
> together. Parallel booting addresses the specifc problem of how to order
> 'attempted' start up
> of service scripts.  There is no reason to say that a later script
> must not be 'attempted' if an eariler script in the ordering has a
> problem.

Sure there is- It is (at the least) inefficient, and often error-prone.

> You are using I think 'dependancy' in an all encomposing way to
> include hard dependancies as well as conditional dependancies. Just
> because a 'dependancy' fails to start doesn't mean a later service
> doesn't launch. Services scripts can have conditional logic...
> foo initscript
> if network is running do this
> if network is not running do that
> bar initscript
> if sshd is running do this
> if sshd is not running do that
> Are completely valid conditional checks that later scripts can use to
> taste the state of the system and decide how to proceed. In these
> cases network and sshd are still dependancies in the sense that they
> need to be 'attempted' to be run for the conditional logic to have any
> validity. The startup scripts for these services still need to be
> 'attempted' before my foo are bar services, but whether or not network
> is running or sshd is running is not a failure state that causes foo
> or bar to not be launced.


Agreed, and in the current initscripts world, this is an absolute necessity, 
however, with adequately specified dependancies such checks per service are 
redundant and inefficient.

I believe that stopping at the head of a dependancy chain (as opposed to 
-forcing- each script to error-check on its own, which is where you're 
implying we should leave it) is better for the following reasons:
 1) Writing state-checking code is typically error-prone and tedius.
 2) Reporting that a link in the dependancy chain failed, and so Foo, 
    Bar, and Baz will not be run is much cleaner than scanning the 
    syslog for failure statments from each of Foo, Bar, and Baz.  This 
    means that it is easier to fix, i.e. more maintainable.
 3) Most of the 'parallel' init schemes that I've seen already use a tool
     which does dependancy checking... i.e. the tools are robust and
    useful in dependancy checking/failure situations.



> Service scripts that depend on something else running should be robust
> enough to have conditional logic and do their own internal checking
> for system state before attempting to doing something spectacularly
> stupid. 

If you rephrased that as: Service scripts should fail gracefully, then I'd 
wholeheartedly agree. I don't view requiring additional overhead as good.
A requirement in a dependancy graph might even be virtual, i.e. depend on
a system logger daemon be running. This seems like a nice way to deal with
things, instead of requiring the script to check for each version of a daemon
that it knows about.

> Lets not drag failure status into the debate about ordering. 
> Each initscript should internalize its own checks and do its own
> conditional logic to check for system state. What parallel bootup
> should be addressing is SOLELY how to order script start up. It should
> not refuse to attempt to start up a script. If a script has been
> requested to be on at boot...it should be run at some point in the
> ordering...and its internal checks should be used to catch system
> state problems.
> -jef


:/

 I feel that using the information provided by dependancies can result in a 
cleaner, easier to fix error condition.. I'm not sure if I know how to 
reconcile the two viewpoints... Perhaps the only way is to just try it :/

-Roberto JP