Upstart 1.0 Design discussion
Scott James Remnant
scott at netsplit.com
Sat Sep 12 03:13:37 BST 2009
On Fri, 2009-09-11 at 17:03 -0400, Casey Dahlin wrote:
> I've had some suggestions for the Upstart 1.0 design which came up
> when I spoke to Scott on IRC the other day. I would like to post them
> here, but for continuity's sake, I figured I'd simply post the 1.0
> design as Scott described it (and I understood it), and then work from
I'll try and describe things in my own words, since the behaviour is
about right but not how I think that it'll work under the hood.
Upstart will have, as it has now, a primary first-class object that it
tracks. I tend towards dislike calling these "states" since these
things themselves have states; Casey suggested "conditions" but that has
implications I don't like.
Upstart internally calls them jobs. Let's just call them that, because
I doubt that the code will ever call them anything but ;-)
Jobs can represent conditions, they can represent states, they can
represent services and they can represent tasks. They may have attached
processes, but they also may not.
(If we use "services" and "tasks" to only ever refer
to jobs with attached processes, then I think it's
Jobs have two principal properties: their state, and their goal. But I
think that this is an implementation detail. From a theoretical
standpoint, we should instead say that Jobs have two Levels.
Transition between these levels is not necessarily instantaneous, Jobs
may be in transition from the ground state to the active state. Here's
________/ | | \________ stopped
I strongly dislike these terms. I actually spent almost a day this week
tracking down a bug in Ubuntu's upstart-native boot caused by using
"start on starting udev" when I meant "start on started udev".
It's also worth pointing out that in practice, these labels should be at
the transition points and not apply to the transitions as a whole. But
meh, theory vs. implementation.
What's important is that there are actually four states. The two states
representing the two levels which are "stable" states (given no further
input, we tend to stay in them), and two states representing the
transition between levels which are "unstable" states (they end
As well as the two obvious conditions as whether a job is at the higher
level or the lower level, useful for depending on the job and being a
dependency of the job respectively, there's another interesting
condition of whether this job *should* be at the higher level:
| / \
There's mathematically the opposite as well, but I can't think of a use
for that one ;)
The condition of whether a job should be at the higher level is
important, it's the one that Upstart changes itself. We've used the
planned "while" stanza for this one.
"while" can reference any other job. You can perform boolean logic with
"and", "or" and "not" and you can group.
while (foo and bar) or not baz
The job's should state is coupled do this; when this condition is true,
the job should be started and the state transition will begin.
Now, you should be asking which of the job's conditions this matches. I
think this matches the upper level, because that's the most _common_ use
should mean while apache is running, not while apache should be running
or while apache is not not running.
However, "while apache is not not running" is important since it's used
for insertion dependencies. A proposed stanza for this is "before", I
just don't like it ;)
Another way might be just to sub-job this:
while apache start
or something. Then we can just add another for the "should" case if we
want to match on that.
This is all well and good for automatic jobs, but we also want jobs that
still respond to good old "events". "while" ensures an instance exists,
but if the job uses an "on" stanza that instance is not automatically
You can use multiple "on" stanzas, any one will start that instance.
What are these events? Well, it's still useful to be able to do this
based on the state transitions of other jobs. Take a "postgresql backup
script" as an example:
on postgresql post-stop
This shows how the "while" and "on" are distinct. We want this to be
stopped should the filesystem go away, but don't want any stopping to
happen based on the state of postgresql - just starting.
I forsee being able to nest any level of sub-jobs like this; for
samba nmbd post-stop
This assumes that events are generated by the state transitions in jobs,
and are named exactly for them and carry the same environment. I think
I also think we still need stand-alone events for things like
"control-alt-delete" and "reboot", etc.
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20090912/29a17a89/attachment-0001.pgp
More information about the upstart-devel