conditonal events to start a script?

[Sean Russell]

On Tuesday 31 October 2006 14:36, paul wrote:
> Yes, I found it. It seams you have already discussed this issue
> in great length. I should have looked in the archives first. My bad.

No problem.

> start on filesystem.writable & xfs.started & (hald.started |
> hald.failed)
>
> or
>
> start on filesystem.writable & xfs.started & hald.[started|failed]

Ok.

One of the desireables is to keep the complexity of the Upstart parser 
to a minimum.  If we work off the current behavior, and add 
multiple "AND" dependencies, then what you suggest could also be 
written as:

	start on filesystem.writable xfs.started hald.started
	start on filesystem.writable xfs.started hald.failed

Which says the same thing and is easier to parse.  Upstart will start 
the service if *either* of these conditions are true.  That is, 
seperate "start on"s act as "||", and multiple events in a 
single "start on" act as "&&".  This means that the current behavior of 
Upstart scripts will not be affected; they'll act as they always have.  
Ergo, in pseudo code:

> I do not think you really need a timeout here (although it might
> be elegant to have it anyway). When you never get the hald.started or
> hald.failed event,  then most likely hald was never started. Which
> means that something else is seriously wrong. Do you still want to
> continue in that case? 

I agree that a timeout would be nice.  In the original Upstart proposal, 
it was suggested that there be a future time-based feature.  That would 
allow you to write something like:

	start on startup+10m

so that you could have:

	start on filesystem.writable xfs.started hald.started
	start on filesystem.writable xfs.started hald.failed
	start on filesystem.writable startup+10m

Meaning, start the service if either of the first two "start on" 
conditions occur, or at latest 10 minutes after the system was started.  
However, I personally believe that the need for a timeout is an edge 
case -- nice to have, but not critical.  I think getting basic multiple 
dependency support is absolutely critical, and the other stuff is lower 
priority.

What would be useful (but also not necessary) is to have a conditional 
flag "?":

	start on filesystem.writable xfs.started hald.started?
	start on filesystem.writable xfs.started hald.failed?

That is, REQUIRE filesystem and xfs, but if hald doesn't exist, then 
start anyway.  Otherwise, you almost have to say that the default 
behavior for all events is conditionally.  The difference would be:

	Case 1 (with '?' support):
	start on X Y Z?
	start on P

=> (X && Y && (Z || ~Z)) || P

	Case 2 (without '?' support):
	start on X Y Z
	start on P

=> ((X || ~X) && (Y || ~Y) && (Z || ~Z)) || P

--- SER