Upstart

[Patrick Goetz]

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.
> 
> However there are "recommendations".
> 
> 
> First is that if the service a job represents emits an event, it uses
> the (purely documentation) "emits" stanza in its job file.  That way you
> can get a rough idea by parsing /etc/init/*.conf
> 
>     $ grep "emits local-filesystems" /etc/init/*.conf
>     /etc/init/mountall.conf:emits local-filesystems
> 
> So local-filesystems comes from the mountall service.
> 

 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.)

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?

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.

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.  <:)

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?

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?