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 <div class="gmail_quote"> On Tue, Jun 7, 2011 at 10:17 AM, Jacek Konieczny <<a href="mailto:jajcus@jajcus.net">jajcus@jajcus.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">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 </div>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 <div><div></div><div class="h5"> -- upstart-devel mailing list <a href="mailto:upstart-devel@lists.ubuntu.com">upstart-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/upstart-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/upstart-devel</a> </div></div></blockquote></div>