Dependencies

[Sean E. Russell]

Arg!!  I didn't see that I was responding directly to Jerry. I'm re-sending 
this to the list -- Jerry, sorry about the dupe.


Oh, I want to make it clear that I think this event-driven init design is a 
wonderful idea.

On Saturday 07 October 2006 11:17, you wrote:
...
> > example, the "netfs" process wait until it receives BOTH network/started
> > and localfs/started events?
>
> We've been considering how to deal with this for a number of different
> problems. My current thinking is that the job should be triggered on
> BOTH events, in any order, and each time it is triggered, it should do
> some work to make sure the other one is currently satisfied.

Hmm.  That would work.  It seems sort of kludgy, though... requiring the 
script to check to make sure that the system is in a given state somewhat 
defeats the purpose of having an event driven process in the first place -- 
at least in the case where the dependencies needed are at no finer grain than 
that generated by the event mechanism (IE, we need local filesystem and 
network, vs. needing /home specifically to be mounted).

I haven't looked at the code (reading C is painful for me), but I can't 
imagine that the init process is:

        1) read all of the files in /etc/event.d
        2) parse them, and build an in-memory index of starts and stops
        3) when an event comes in, look through the index for listeners of the 
event
        4) call the script

(this ignores pre- and post- scripts).  As opposed to, say, reading the 
event.d directory EVERY time an event comes in.

What you're proposing is offloading the effort of keeping track of which 
events have come in onto the scripts, which are stateless.  It is much less 
effort for the init process -- which IS stateful -- to keep track of these 
events than it is for the scripts.  Not only are you making it harder to 
write such scripts by offloading that work onto the scripts, but EVERY script 
will have to deal with state, meaning much duplicate code.  On top of this, 
it could become quite expensive.

Consider the case where some script needs three or four events to have come 
in, and checking for the state of each event can take several hundred 
milliseconds (say, one has to do an arping, one has to query the USB bus, one 
has to look for a PCMCIA card).  Each time one of these events comes in, ALL 
states have to be checked for.  I don't believe that this is a wild edge 
case.  If the init process keeps track of the events that it has delivered, 
then it is much more efficient and easier to write scripts.

The simple implementation wouldn't affect the complexity of the scripts, or 
drastically affect the complexity of the init process.  A more complex 
implementation would have mechanisms for allowing scripts to perform checks 
on each type of event, returning true (partial satisfaction of start/stop 
conditions, so init considers that event requirement met) or false (does not 
satisfy start/stop condition, so init leaves the event requirement in the 
queue).  I'm not sure that this level of complexity is necessary -- I'm only 
peripherally thinking about the sorts of problems that it would address.  But 
it seems obvious that scripts requiring multiple events to occur before they 
can start will be -- and are -- common.

I'm sure you've thought about all this, so I'd be interested to hear the 
reasoning for having the scripts track the system state.

> > Also, I'd like a pointer to any discussion about conditional use cases. 
...
> Cups is a hard one. I'd say it should either watch the network on it's

Well, Cups was just an example.  The Gentoo init scripts are full of examples 
of services which have conditional requirements.  The idea is that there's a 
mechanism for saying "if this service is going to be started, then wait for 
it to start.  Otherwise, just start now."

> A lot of those features barely even exist. I think the best we've got
> about where we're going is a wiki page:
> https://wiki.ubuntu.com/UpstartDesignChanges

Oh, OK.  I thought I had read something about Upstart already supporting 
multiple event prerequisites... but I can't find the page now, and I may have 
simply misunderstood the feature that services can register to listen for 
multiple events.

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