Alternative Init System

[Phillip Susi]

Tristan Wibberley wrote:
> 
> 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).
> 

Actually, my answer is the services should be combined, not split up. 
If they are so tightly coupled that one can not run without the other, 
then it is really only one service and should be started as such.

>> 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 

What is being deduced and what is doing the deduction?  If I understood 
you correctly you were suggesting that the services just be all started 
at once, and when they reach a point where they require another service, 
they should simply wait for that service to start rather than abort. 
Effectively that is removing the dependency because one no longer 
depends on the other to start.

> 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.
> 

Why does that need to involve init?  If the service itself decides from 
it's config file that it needs another service, it is up to that service 
to wait around for the other service to start up.


> 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.
> 

Is there a plug and play mechanism for network interfaces?  The server 
would have to be notified when a new interface is enabled so it could 
consult its config file to decide if it should listen on that interface.

As for the login type programs, they should be modified to perform 
whatever other startup work they have, such as drawing the login screen, 
and only bother to try to talk to pam when the user enters their 
credentials, possibly with a few auto retries if pam isn't started up 
yet.  I wonder why they don't already behave this way?