Alternative Init System

[Tristan Wibberley]

Phillip Susi wrote:
> Tristan Wibberley wrote:
>>
>> NT does not handle this properly. Service granular dependency is not 
>> even descriptive enough to cope properly with the needs of the 
>> services of a plain Exchange server. That's why you get mysterious 
>> warnings and errors in the event log that are not warnings and errors. 
>> I think 
> 
> It allows you to describe what other services this one depends on by 
> name or group, what more do you need?  If certain services fail to 
> properly utilize it that's neither here nor there.

In the case of exchange, it is to avoid a service explosion where 
logical units are separated into so many parts that it becomes 
unmanageable. One service fails to start correctly because it doesn't 
depend on another service simply to avoid a cyclic dependency due to 
having to avoid splitting closely related code. The service then tries 
to complete its startup later on. (I'm expecting a "it should split the 
service up" answer to this, please read on first as I think I cover it 
later - demonstrating a near equivalence but with nicer features).

>> feature granular dependency is required, IMHO, which requires that 
>> services all just start and block early, either on IO, or waiting for 
>> the features they depend on to start.
>>
>> It means dependencies can be discovered from service configurations 
>> rather than being statically conservative, and parallelism is used to 
>> the utmost.
>>
> 
> That's simply removing dependencies altogether.

I don't think it is. I think it is using services to deduce the 
dependencies for features from its own configuration. Essentially it is 
like hierarchical services where init has a configuration for a number 
of services, and those services have configuration for sub-services. 
This avoids service explosion, keeps duplication of code to a minimum, 
and correctly applies strict dependency processing, while keeping disk 
queues full. When a dependency is known statically, you can put that 
dependency into init, when it is only known after parsing of a services 
configuration file, the service should make that part of it depend on 
stuff as soon as it can.

> That certainly is a 
> nice idea when practical, for instance, the X server should be able to 
> start up, and the gdm login paint the login prompt before the mouse is 
> detected and configured.  It can begin to function later without holding 
> up X and gdm from starting.

> I wonder if we can come up with a list of services that currently fail 
> in situations like that but could probably be modified to just do the 
> right thing when the other service comes online later, and a list of 
> services that already will work fine when launched in parallel but are 
> configured to start sequentially.

Ones that I think need to start up before their full dependency list can 
be known:

* GDM (pam login methods are only known by pam),
* Apache (only apache knows which interfaces it is going to listen on 
and it should start listening on them as soon as they appear even though 
the others may not be up yet).
* postfix (similar reasons to apache)
* OpenLDAP (similar to both GDM *and* apache)
* Samba (more of the same)

I've clearly lost the ability to be imaginative, but I'm sure more will 
turn up. Those above will probably have static dependencies too.

-- 
Tristan Wibberley