Upstart

[Scott James Remnant]

On Fri, 2010-03-05 at 12:09 -0600, Patrick Goetz wrote:

> Scott James Remnant wrote:
> > Anyone can emit any event.  That's probably the bit of Upstart that
> > people find the hardest to get to grips with, so there can never be any
> > comprehensive list of every event and every argument - because anyone
> > can add a new one.
> > 
> From a system administrators' perspective, this sounds like a debugging 
> nightmare, since anyone not documenting an emitted event as outlined 
> above leaves you with no idea of what is going on or how things 
> interact.  I think it's extremely important to either have or be able to 
> produce a text file which definitely indicates the sequence(s) of 
> [particular] event dependencies.  (I.e., I don't want to rely on 
> someone's remembering to put a comment in a text file, I want to know 
> what's actually going on for sure.)
> 
An event is simply an abstraction of some kind of change to your
computer's state; it might be new hardware being detected, it might be a
particular filesystem (or group of filesystems) being mounted.  It might
even be the user pressing a key combination on the keyboard, or shutting
the lid.

They don't have "dependencies", nor do they have ordering or sequences.


Upstart was designed from the principle that since we can no longer
control the order that things happen in, or even whether certain things
happen, we should instead design a system that lets you define what a
service needs.

You can't know what's going on for sure without letting the computer
boot and see what happens.  You might have forgotten to plug your USB
mouse in this boot; or maybe your cat has chewed the ethernet cable
overnight and it won't come up, etc.


> The events are emitted over D-bus?  Unfortunately I don't know much 
> about d-bus, so pardon my ignorance if this is a dumb question, but is 
> there some kind of Upstart d-bus configuration file which documents all 
> the events the upstart daemon is configured to handle?  How does Upstart 
> decide how to sequence services based on the events they emit?
> 
D-Bus is used to communicate with the init daemon, and one of the method
calls you may make is to emit an event.  The event name is simply a
string, and the arguments an array of strings.  There's no need to
configure Upstart to accept certain events, you just make them up as you
go along.

Upstart doesn't "sequence services".

> Perhaps a specific example would help:
> 
> Let's say, for the sake of argument, that autofs is failing to start 
> because of some daemon initialization timing problem (I use this example 
> because this is a problem we've actually had with Ubuntu desktop clients).
> 
> 1.
> How would I go about figuring out what the *linear* sequence of events 
> is related to the autofs service?  I.e. I understand that lots of stuff 
> is going to be started in parallel, but I want to know the startup 
> dependencies for that particular service.  This was very easy to figure 
> out with System V init on Debian:
>    ls /etc/rc2.d
> followed by a few peeks at files in /etc/init.d.
> 
There is no *linear* sequence of events.  Purge that assumption from
your mind.

In an Upstart system, you look at the "start on" (or "while" in future
versions) line in the /etc/init/autofs.conf file.  That tells you what
condition will cause autofs to be started/running.

> 2.
> OK, I've rolled out Ubuntu X.Y and discover that a (mission-critical) 
> service is not starting because of an event sequencing boo-boo, 
> intermittent timing problem, or what not.  In 9.4, for autofs, we solved 
> this by throwing a few sleep 1's in the /etc/init.d/autofs file
> What recourse do I have to fix the problem myself on an Upstart-based 
> system?  Please note that in trenches one encounters fire-breathing 
> dragon users who aren't satisfied with the response "oh, we logged a bug 
> on launchpad, so this should be working in a couple of weeks -- we 
> hope.".  System administrators who like to stay employed are most 
> comfortable with solutions, even if hacks or band-aids, that they can 
> deploy themselves while waiting for the Olympians to act.  <:)
> 
Simple; you'd modify the /etc/init/autofs.conf file and either fix the
"start on"/"while" line (which must be wrong if the service is failing
to start) - or modify the script/exec lines to correct how autofs is
started.

> 3.
> I have to install a commercially provided service and these bozos 
> couldn't care less about dpkg, Ubuntu, or anything other than their 
> lucre (why is lucre always filthy?).  The service is probably a license 
> manager, or something like this.  How does this interface with the 
> Upstart Init system?  Just stuff everything into /etc/rc.local and hope 
> for the best?
> 
If you're providing something commercially, and aren't particularly
targeting any distro, you should follow the LSB specifications - which
include things like service management.

Ubuntu implements these LSB specs.

> 4.
> Presumably there must be developers' documentation for Upstart so that 
> services can be coded to emit d-bus events?  Where might one find this 
> documentation?
> 
Partial documentation for the D-Bus API exists here:

http://upstart.ubuntu.com/wiki/DBusInterface

It's usually easiest to just fire up d-feet and prod it; it's pretty
obvious.

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20100305/6f68932d/attachment.sig>