Upstart helpers (abstract jobs and event aliases) for Oneiric

Jan Claeys lists at
Wed Jun 8 01:35:34 UTC 2011

James Hunt schreef op di 07-06-2011 om 15:00 [+0100]:
> === Implementation ===
> There are two simple methods here we're considering.
> ==== 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
> ===== Observations =====
> - This might *appear* to be inefficient in that Upstart must check every
>   time *any* job starts to determine if DISPLAY_MANAGER=y is set in that
>   jobs environment. However, there is no additional overhead beyond how
>   Upstart currently works. Consider that...
>     start on starting gdm
>   ... is actually an alias for:
>     start on stating JOB=gdm
> - This would require *every* package that provides a service to be
>   updated. Admittedly this would only need to be done once though.

At least for every package that wants to support this...

> - Might be confusing since users you *must* specify "=y" exactly
>   (dropping the "=y" won't work, and nor will specifying "=Y" (or "=1")).

So, why not use something like SYSTEM_SERVICE=display-manager instead?
That would be less confusing...

The main disadvantage for this is that the start/stop/etc. command don't
work without a job name.  So you can't do a 'restart firewall', but you
have to check what firewall service is running, and then  restart that
job.  I'm not 100% sure this is bad or good though (services might have
different (default) behaviour despite providing the same service)?

> ==== Option 2 ====
> Create a Job Configuration File that hard-codes the list of known
> service providers. For example for "display-manger", we could have:
>   start on (starting gdm
>         or (starting kdm
>         or (starting lightdm
>         or (starting lxdm
>         or (starting slim
>         or (starting wdm
>         or  starting xdm))))))
>   stop on (stopping gdm
>         or (stopping kdm
>         or (stopping lightdm
>         or (stopping lxdm
>         or (stopping slim
>         or (stopping wdm
>         or  stopping xdm))))))
>   env    ABSTRACT_JOB=y
>   export ABSTRACT_JOB
> ===== Observations =====
> - Since this is an Abstract Job, it will have no PID, but this job will
>   "run" for the duration of the first display manager to be invoked.
> - We appear to have simply "moved the problem" since although we are no
>   longer hard-coding the list of display managers in "plymouth.conf", we
>   are hard-coding the list now in "display-manager.conf". However, we
>   have gained by doing this since:
>   - We have still created the level of abstraction desired.
>   - We have contained the problem into a single file: we define the list
>     of display managers *once*.
>   - We don't need to update every Ubuntu (and potentially every Debian)
>     package as would be required for "Option 1".
>   - We *could* conceivably auto-generate "display-manager.conf" from the
>     archive with a simple script which munged the output of:
>     apt-cache search x-display-manager|awk '{print $1}'|sort

For some reason this doesn't give a complete list of all display
managers in the repository (maybe some of them aren't meant to be run at
boot like that, but some certainly do--that might be a bug in those
packages?), but more importantly this will never include display
managers that aren't in the official repositories.

> - The "ABSTRACT_JOB" variable would allow other jobs to detect that a
>   job was abstract (they shouldn't need to care, but just in case...)
>   This also avoids the unwieldliness of "abstract-display-manager" (or
>   even "abstract/display-manager" (were we to put the abstract jobs in
>   /etc/init/abstract/ say).

Jan Claeys

More information about the upstart-devel mailing list