Upstart helpers (abstract jobs and event aliases) for Oneiric
Marc - A. Dahlhaus
mad at wol.de
Wed Jun 8 13:59:04 UTC 2011
Hi James,
Am Mittwoch, den 08.06.2011, 14:18 +0100 schrieb James Hunt:
> Hi Marc,
>
--8<--
> >> == Proposal 1: Provide Event Aliases for Common Scenarios ==
> >>
> >> Create event aliases as shown below:
> >>
> >> |----------------+------------------|
> >> | Existing Event | Event Alias |
> >> |----------------+------------------|
> >> | runlevel 0 | halt |
> >> | runlevel 1 | single-user-mode |
> >> | runlevel S | single-user-mode |
> >> | runlevel 2 | multi-user-mode |
> >> | runlevel 6 | reboot |
> >> | runlevel [016] | shutdown |
> >> |----------------+------------------|
> >
> > Will this events get emitted by upstart itself?
> No, they don't need to be. Upstart has no concept of runlevels - they are just events. Hence, these
> aliases would not be emitted by Upstart itself, but rather by a job configuration file, such as:
>
> start on runlevel
>
> task
>
> script
> case "$RUNLEVEL" in
> 0) events="shutdown halt";;
> 1|S) events="shutdown single-user-mode";;
> 2) events="multi-user-mode";;
> 6) events="shutdown reboot";;
> esac
>
> for event in $events
> do
> initctl emit $event
> done
> end script
ok, thats simple.
> >
> >> == Proposal 2: Provide Abstract Jobs for Common Services ==
> >>
> >> |-----------------+-------------------------------------------------------------------|
> >> | Abstract Job | Description |
> >> |-----------------+-------------------------------------------------------------------|
> >> | display-manager | gdm, kdm, lightm, etc. |
> >> | network-manager | NetworkManager, wicd, connman, etc |
> >> | firewall | ufw alias. |
> >> | network | started when *all* configured network interfaces and bridges "up" |
> >> | graphics-card | starts when first graphics card added to system. |
> >> |-----------------+-------------------------------------------------------------------|
> >>
> >> === 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
> We could make this slightly better by having /etc/init/display-manager.conf:
>
> start on starting DISPLAY_MANAGER=y
> stop on stopped DISPLAY_MANAGER=y
>
> So that you could then say in foo.conf:
>
> start on starting display-manager
mhm. I thought about the other way of chaining the events so that eg.
gdm starts on starting display-manager...
> > --8<--
> >> ==== 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
> > --8<--
> >
> > Well, i don't like Options 1 and 2 as they look as hackish as the things
> > you want to get rid of in the first place...
> As I said, ugly. But they do have the benefit of extreme simplicity (kiss... :-)
>
> >
> > [RFC] Option 3:
> >
> > add an new "alias" stanza that sends an event (in parallel to all of the
> > jobs main events) with JOB=$alias (and waits for booth to complete where
> > appropriate).
> I had already considered a slight variation but discounted it since as shown, you can provide
> atleast a subset of the required behaviour without any changes to Upstart. However, having mused on
> this, I'm coming round to the idea of an "alias" stanza since as you mention it allows initctl to
> work as expected when the user says "start display-manager" and that is clearly important [1].
>
> For the scenario where a user has, say, multiple display managers installed all of which specify:
>
> alias display-manager
Can't be the case if the system is configured the right way IMO.
If you have multiple active jobs that reference the same alias its a bug
because they would race. We could simply check to the manual stanza that
alternatives have to set when deactivating alternatives.
> Running "start display-manager" is clearly ambiguous. However, we could handle this by having
> initctl fail immediately with an error such as:
>
> $ start display-manager
> start: ERROR: Alias display-manager resolves to multiple jobs (foo-dm, gdm, lightm)
>
> This could then be resolved either manually...
>
> $ start display-manager JOB=gdm
> display-manager (gdm) start/running, process 1234
> ... Or, maybe by "forcing" start to select one of the providers:
>
> $ start --force display-manager
> start: Resolved alias display-manager to job foo-dm
> display-manager (foo-dm) start/running, process 1234
>
> We could also allow an optional job to be specified to the "alias" stanza such that we could create
> /etc/init/abstractions.conf (or maybe allow content in /etc/init.conf):
>
> # this job cannot be started
> manual
>
> alias display-manager gdm
> :
> alias display-manager xdm
>
>
> alias network-manager connman
> :
> alias network-manager wicd
>
> >
> > As all "Common Services" should be mutually exclusive installed,
> We can't really make this assumption.
let me rephrase it a bit:
A "Common Services" should start mutually exclusive.
We cant start two services of the same type as long as we have only one
resource (in this case the display) they are racing to access and use on
startup.
So if we have more than one active display-manager in the upstart event
chain we have a bug. Or am i missing something?
> so each
> > of them can use the same alias stanza value.
> >
> >
> > Marc
>
> [1 - I think this is a key point since if we don't care that much about initctl not allowing us to
> say "start <display manager>", the "alias" stanza doesn't really buy us much over the existing options.
mhm. I thought about ease of documentation...
> Regards,
>
> James.
>
thanks,
Marc
More information about the upstart-devel
mailing list