Upstart helpers (abstract jobs and event aliases) for Oneiric

Jacek Konieczny jajcus at jajcus.net
Wed Jun 15 11:05:13 UTC 2011


On Tue, Jun 07, 2011 at 10:45:25AM -0700, Scott James Remnant wrote:
> This shouldn't be the case unless you also put "export SYSLOG" in the jobs
> that use "start on started..." - environment isn't copied from the start
> event into the new start event

I think I can see my error now: I used a single 'SERVICE' variable with
different values per job and in such case the value is inherited by
other jobs with 'export SERVICE'. It is now clear to me why James
suggested 'DISPLAY_MANAGER=y' and not something like
'SERVICE=display-manager'. This should, indeed, work.

> 
> On Tue, Jun 7, 2011 at 10:17 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> 
> > 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:
> > >
> > >   DISPLAY_MANAGER
> > >   FIREWALL
> > >   GRAPHICS_CARD
> > >   NETWORK
> > >   NETWORK_MANAGER
> > >
> > > For example, each display manager package would be updated such that its
> > > .conf file specified:
> > >
> > >   env    DISPLAY_MANAGER=y
> > >   export DISPLAY_MANAGER
> > >
> > > 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…
> >
> > Greets,
> >         Jacek
> >
> > --
> > upstart-devel mailing list
> > upstart-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/upstart-devel
> >

> -- 
> upstart-devel mailing list
> upstart-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel




More information about the upstart-devel mailing list