init: allow multiple 'on' statements

Reported by ensc on 2009-12-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
upstart
Wishlist
Unassigned

Bug Description

It would be nice when multiple 'start on' statements which specify alternative start reasons are possible (again). E.g.

start on A
start on B

would have a semantic of

start on (A) or (B)

Although this wish does not add something new and can be reached by existing mechanism already, multiple statements are much easier to configure. It will be possible e.g. by simple 'sed' one-liner to specify additional start conditions or remove such ones. Currently, a complex parser (which might have to go across multiple lines) and complex substitution rules are required to change startup conditions.

The plan is to support multiple 'while' statements, where each one is joined by AND - and multiple 'on' statements, where each one is joined by OR.

  while filesystem
  while gdm
  on control-alt-delete
  on lid-closed

Type thing

Changed in upstart:
status: New → Triaged
summary: - RFE: allow multiple 'start on' statements
+ init: allow multiple 'on' statements
Changed in upstart:
importance: Undecided → Wishlist
Casey Dahlin (cjdahlin) wrote :

Some notes.

1) The current behavior of start on completely violates the principle of least surprise. There is no situation in which "start on foo \n start on bar" will do something the user actually wants, which means the user will always get something they didn't expect. Having the job fail with multiple start ons would be better than what we have.

2) we've said we'll keep 0.6 compatibility. There's been a lot of talk of modes and detection and separating jobs, when really the best way to do that would be to just /don't remove start on and stop on/. Using them can set off all kinds of buzzers and alarms and "you're doing it wrong" notices, but just leaving them in completes our backward compatibility with little additional effort.

On Mon, 2009-12-07 at 20:15 +0000, Casey Dahlin wrote:

> 1) The current behavior of start on completely violates the principle of
> least surprise. There is no situation in which "start on foo \n start on
> bar" will do something the user actually wants, which means the user
> will always get something they didn't expect. Having the job fail with
> multiple start ons would be better than what we have.
>
This is consistent with all other stanzas.

> 2) we've said we'll keep 0.6 compatibility. There's been a lot of talk
> of modes and detection and separating jobs, when really the best way to
> do that would be to just /don't remove start on and stop on/. Using them
> can set off all kinds of buzzers and alarms and "you're doing it wrong"
> notices, but just leaving them in completes our backward compatibility
> with little additional effort.
>
What's this got to do with anything?

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers