Upstart helpers (abstract jobs and event aliases) for Oneiric

[Jan Claeys]

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:
> 
>   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
> 
> ===== 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