Upstart helpers (abstract jobs and event aliases) for Oneiric

Jacek Konieczny jajcus at
Tue Jun 7 17:17:26 UTC 2011

On Tue, Jun 07, 2011 at 03:00:03PM +0100, James Hunt wrote:
> ==== Option 1 ====
> Update every package that provides a service such that its Job
> Configuration File sets and exports a "well-known" variable. The
> proposed list of environment variables which represent these services
> is:
> For example, each display manager package would be updated such that its
> .conf file specified:
>   env    DISPLAY_MANAGER=y
> Then, any job that requires a display manager could say:
>   start on starting DISPLAY_MANAGER=y

I have tried a similar approach in PLD Linux. We allow multiple syslog
implementations there, so I made syslog-ng do:

env SERVICE=syslog
export SERVICE=syslog

and in dependant jobs:

start on started SERVICE=syslog

That seemed to work well… but it didn't quite behave as expected. The
problem was every service started via 'start on started SERVICE=syslog'
inherited the 'SERVICE=syslog' variable and would trigger other jobs
start (that was not visible at first, as those jobs would be usually
already running because of the first event with SERVICE=syslog).

I am not sure this is expected behaviour of Upstart or if it can be
changed, but Option 1 clearly didn't work for me. Though, I would prefer
this way over 'Option 2'.

'Option 2' (abstract job explicitely listing real jobs that trigger it)
may be good for a well-defined 'contained' distribution like Ubuntu, but
not a 'everybody may add his stuff' distribution like PLD Linux… or
Ubuntu with all the unofficial package repositories. Auto-generating the
job definitions would help, of course… but weren't the Upstart job files
intended to be human readable and human writable?  If we start a
precedence of machine generated job descriptions we may end with another
layer of machinery over Upstart…


More information about the ubuntu-devel mailing list