In-Upstart init Proposal for Multi-Event Dependencies

Some services require that more than one other service be started before they can start. Upstart needs some form of multi-event dependency support to handle this.

Minimal Multiple Dependency Support

This proposes a minimal feature set of within-Upstart support for multiple dependencies. The goal is to keep the number of changes in Upstart to a bare minimum to support the basic features. Along this route, functional trade-offs are made, and some behaviors are debatable.

This proposal suggests a modified syntax allowing multiple, space separated, events to be listed for an "on" event, and the addition of an optional token "?":

start on X Y Z?

This creates a "sufficiency" list; the service will only be started when all of the events listed are satisfied. Satisfaction of a dependency occurs when either:

• The event occurs
• The event does not exist and is modified by the optional flag "?" (a soft dependency, like Gentoo's "after")

Upstart would need to change very little to support this feature set, and this level of support would likely be sufficient to cover most dependency needs.

In the above example, the service will be started when events X, Y, and Z (if Z exists in the filesystem) occur.

Examples

For a given service K:

start on A/started

This is the same as the current Upstart behavior. (K if A/started)

start on A/started
start on A/failed

K starts after A, even if A fails to start. Same as the current Upstart behavior. (K if A/started || A/failed)

start on A/started B/started

K starts only after both A and B have started. (K if A/started && B/started)

start on A/started B/started?

K starts after A has started, and after B has started if B exists in the filesystem. (K if A/started && (B/started || !B))

start on A/started B/started
start on A/started B/failed

K start after A has started, and after B either starts or fails. This means that K will not start if B does not exist in the filesystem. (K if (A/started && B/started) || (A/started && B/failed))

Optional Deviation

The soft dependency "?" could be eliminated by specifying that the default behavior is that all dependencies are soft dependencies. This is appealing in that it is orthogonal to the current Upstart behavior, in which all dependencies are considered optional:

start on A
start on B

Upstart will start the service if A or B occurs. Under this design,

start on A B

this service will be started if:

• A occurs and B is missing
• B occurs and A is missing

• A and B both exist, and occur

(K if (A || !A) && (B || !B))

This will make the Upstart parser more simple, but removes the ability to express hard dependencies: dependencies which mean "do not start unless both events exist". Since it does not significantly simplify the sufficiency algorithm, it buys us little in terms of simplicity.

Coverage

The current Upstart syntax only supports OR dependencies. The proposed syntax would provide AND dependencies and allow for soft AND dependencies. This should be sufficient to most of the desireable dependency trees.

This does not address the soft dependency situation where an event exists in the filesystem, but is never triggered; this is an unsolvable problem in an event-based architecture.

This does not address events not controled by event.d scripts. To ensure accurate dependency coverage for external events (initctl foo), add such an event with circular dependencies ("start on foo/started") to the event.d directory.

=== A Brief Comment About Full Boolean Logic Support ===

It has been proposed, and considered, that Upstart support full boolean logic expression in dependency lists, of the sort:

start on ( ( A AND B ) OR C )

I suggest that, while more expressive, it provides little additional functionality that is not achievable with the "Minimal" proposal; what functionality it does provide is in support of edge cases; and that such functionality is bought at the cost of a great increase in the complexity of both the parser and the sufficiency evaluator.

Mailing list discussions

This is the start of the discussion.

http://lists.netsplit.com/pipermail/upstart-devel/2006-October/000694.html

CategoryLookMergeDelete