Sean E. Russell
upstart at ser1.net
Sat Oct 7 21:28:04 BST 2006
On Saturday 07 October 2006 15:01, you wrote:
> One of the perils of the "Release Early, Release Often" approach is
> that you'll have people come to you expecting the Moon on a Stick, when
> you're still in the process of figuring out how to get there.
Yeah, as I said to Jerry, I was under the misapprehension that Upstart already
supported meta-events (IE, an event as defined by a set of events), probably
because I misinterpreted what the multiple-event listening feature.
> The more complex cases of events with arguments and environment,
> collections of events, waiting for multiple events, etc. are still on
> the drawing board.
Great. I'm very interested in following this discussion. As I mentioned, I
was trying to build a set of Upstart event handlers for Gentoo, which already
has a sophisticated -- but not event driven -- init system, supporting
complex and conditional dependencies. The conversion raises a lot of
questions about how the same jobs will be done under Upstart, but I'd love to
at least get to a point where I can boot the system under the new init
> You seem to have some pretty good ideas about how you want things to
> work, please elaborate on them -- the most important part of design is
> having good use cases to start with.
Gladly, but to be honest, they aren't my ideas. As I said, Gentoo's init
system is fairly sophisticated, and I'm only raising issues because I'm
trying to decide how to translate the interrelationships of services.
However, Gentoo's system does not support (natively, or well) parallel
service starting, and it isn't event driven -- and I agree that this core
feature is a significant and powerful paradigm shift. I suspect that
Gentoo's system is somewhat complex in implementation, and inefficient,
although I have no metrics to support that.
I've played with initng as well; I liked it a lot, but it is very easy to
wedge initng, and this happens a lot on seemingly trivial upgrades. So now
I'm back to using Gentoo's vanilla init.
I was also very interested in Apple's launchd...
But Upstart, through its core design, trumps all of these in potential, and I
do think that -- if it proves robust -- it *can* eventually replace a number
of other traditional services (cron being the obvious one).
> Jerry's already pointed out our thoughts on improving events beyond just
> a simple string, and improving the job state machine to fulfil some more
> use cases. He's been extraordinarly helpful in these ideas, and is just
> a community member like yourself.
I thought that Jerry was suggesting having the scripts handle state. That's
not the same as having Upstart have a non-trivial state machine, because the
scripts are doing all of the work. Did I misunderstand him?
> Searching is easy: http://www.google.com/ with
> "site:lists.netsplit.com" as the first keyword. I don't think I've ever
> used a list server's own search interface.
Thanks. I'll give that a shot. Ironically, while I use Google for
*everything* else, I always forget that it makes a decent list archive
resource if one can remember the syntax for restricting the search to a
> The list is also indexed/searched by gmane:
I looked at gmane, but only found the list announcement -- and even now when I
check it, I only see our current discussion, not the entire archive:
> There is no formalised syntax yet, it's still a rough work in process.
> There's no way to handle multiple event dependencies yet, what syntax do
> you think would work best for this?
It might be useful to have a syntax definition, from a design perspective.
It'd certainly make a useful reference for users.
If Upstart were going to handle meta-events, and IF* it were going to be a
simple "act if ALL events have come in", then my reflexive suggestion would
be to simply extend the current syntax to accept a list of events, rather
start on network/started localfs/started
Order is unimportant. Start will only be called after BOTH network and
localfs are started, regardless of what order they came in.
Implementationally, this would probably turn the listener list from a simple
hash map into a more complex structure. Although, the init process MUST
already be tracking process state, so it might be a simple matter of adding
another event map.
> The reason most things are about sysvinit handling is simply that that's
> been the first priority; being backwards compatible is a *big* important
> first step, and helps us test the ideas without losing the ability to
> revert to sysvinit in case it all goes wrong.
Sure, and sysvinit is Very Common. It is a good choice for an initial target.
I'm glad it is detached from the rest of Upstart, though, because there are
distributions which do not use sysvinit.
> The next step is the one you're taking :) Please don't stop taking it,
> your help will be invaluable in getting this right.
Well, thanks for working on Upstart. I know that OS projects are very time
### http://www.ser1.net jabber.com:ser ICQ:83578737
### GPG: http://www.ser1.net/Security/ser_public.gpg
More information about the Upstart-devel