Sean E. Russell
upstart at ser1.net
Sat Oct 7 21:30:29 BST 2006
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
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
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:
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
### http://www.ser1.net jabber.com:ser ICQ:83578737
### GPG: http://www.ser1.net/Security/ser_public.gpg
More information about the Upstart-devel