Alternative Init System

[Tristan Wibberley]

Redirected from ubuntu-devel until there is a forum for community 
development discussion.

Phillip Susi wrote:
> 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.

I think you should look at the services on an exchange server before 
suggesting a solution to that particular problem. They absolutely 
*cannot* be combined.

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

I am suggesting that a service come along with some code to determine 
its requirements and inform init of what they are, which then waits for 
notification that the dependency has started before starting the service 
proper. I suppose you could think of this as polymorphic, non-static 
dependency calculation/service start triggering - if you like that 
description instead.

If a service just waited for the ones they need, it would never start 
since init wouldn't know to start them up. Consider a desktop system. 
Init should trigger gdm dependency calculation and similarly for 
networking, dbus, udev and hal, and probably not a lot else, initially. 
GDM's dependency calculation would be integrated into the same process 
since that has the config file processing (libpam) linked in.

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

That service needs to tell init to start the other service, and init 
needs to know that the depended upon service can be shutdown when this 
one shuts down, that this one should be told when the depended upon 
service has restarted or been reconfigured, etc.

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

A service can put a notification script in /etc/network/if-up.d, or use 
dbus if it doesn't mind breaking when a dbus security update is released 
(unless the dbus service restart problem has been resolved upstream - 
was a WONTFIX the last time I read about it on the Ubuntu wiki).

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

Perhaps they do, but they don't tell init to start up the credential 
authentication services that they depend upon, thus they don't provide 
for init to tell them when those services have started.

-- 
Tristan Wibberley