Dependencies

[Sean E. Russell]

On Tuesday 10 October 2006 09:16, you wrote:
> > Well, then, all of the situations can have a well-defined, reasonable
> > behavior.  To re-iterate, a conditional requirement is considered
> > satisfied if (0) it isn't present in /etc/event.d, (1) it fails, or (2)
> > it goes into a wait state.
>
> Or is started?

Er... yeah.  That too.

> > Or, in Gentoo speak:
> >
> > 	need a
> > 	need b
> > 	after c
>
> Could you elaborate a little more on what the effect of this is?  I'm
> not familar with Gentoo's init system.

It means the same thing that we've been talking about.  "need" means "don't 
start me unless the dep starts"; "after" means "if dep is going to be 
started, start me after dep starts.  Otherwise, just start me."*

Upstart's event driven design obviates "after" functionality, unless Upstart 
gets some sort of multi-event dependency mechanism (which I really think is 
critical).  Again, consider what this might mean:

	start on network/started filesystem/started cron/started?

"Start me when both network and filesystem have been started, and after cron 
has been started/failed if cron exists."  Very useful.

One could argue that the best solution would be full boolean logic support:

	start on network/started & filesystem/started & (cron/started | cron/failed)

Which is more expressive.  However, I think that -- while it would allow more 
explicit rules about when a service is started -- it could also be 
detrimental to the goals of (1) keeping the init process small and simple, 
(2) making it easy to write jobs, and (3) restricting the ambiguity of when 
jobs will be started.  So, I'm not convinced that it is necessary, worth the 
complexity, or advised.

> > This is somewhat tedious for event maintainers.  A better solution would
> > be if jobs can define their own event names, so that "metalog" would
> > generate "logger" events.  This would make systems maintenance much
> > easier, but isn't strictly necessary.
>
> Jobs can emit any event names that they wish through initctl, it would
> not be unusual for jobs to agree on a common event that is emitted (e.g.
> "mta-ready").

So, if I'm a Gentoo maintainer, and I'm trying to write these event scripts 
for a bunch of packages that the users can optionally install, then I can 
write the metalog and syslog scripts such that they both emit "logger/*" 
events when they start/stop/wait/etc... or do I *specifically* have to emit 
events via initctl?  Ultimately, I want to be able to overwrite the default 
name (which comes from the script) with my own.

Again, I don't think that's nearly as important as multi-event dependencies. 
In fact, it may be a non-issue -- whereas, in Gentoo, all init scripts live 
in /etc/init.d whether they're actually enabled or not, in Upstart, events 
are in /etc/event.d IFF they're enabled.  Therefore, you won't (likely) have 
two logger (EG) service jobs in /etc/event.d at the same time, so their 
scripts can be named the same.  IE, syslog will install /etc/event.d/logger, 
and metalog will install /etc/event.d/logger, and syslog-ng will 
install /etc/event.d/logger... and it will simply be a conflict to have two 
installed at the same time.  Something bothers me about this, but I'm not 
going to worry about it too much :-)



* Actually, there are two kinds of conditional dependencies, and I've been 
focusing on one: the "after" analog.  This sort of dependency is met if it 
starts, fails, goes into a wait state or doesn't exist.  A conditional 
dependency can't STOP a service from starting; it only says that a service 
wants to start after some other service if that service exists.

The other sort of conditional dependency is more strict.  It says that if a 
dependency exists, it _must_ succeed before the depending service can start.  
That is, it is OK if the dependency is missing, but not that it fails (or is 
waiting).

-- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido|Iaido
### http://www.ser1.net  jabber.com:ser  ICQ:83578737 
### GPG: http://www.ser1.net/Security/ser_public.gpg