Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


The current job definition format allows only the simplest of event configuration, a list of OR'd events stating when the job will be started or stopped. This specification proposes a new complex scheme for when that is not sufficient.


The simple scheme is useful for tasks, which are often started as a result of either only one or a choice of events. It's also useful enough for simple services that are started and stopped by one other thing. It is not flexible enough to handle the majority of cases that we encounter, this specification fixes that.

Use cases


This specification is limited to the definition and implementation of the new syntax, it relies on the JobsAsState specification to allow this syntax to be split amongst multiple files.



This specification introduces a new configuration file stanza that defines a state based on a parsed set of events.



The following precedence is defined:


The following operands are defined:


Combinations of these stanzas can be used to dramatically powerful effect:

The JobsAsStates specification allows a file in /etc/event.d to contain just a complex event configuration, when combined with the with stanza, this allows custom states to be defined.

It should be noted that the intent of this complex configuration is not to define the causes of a job starting or stopping, but the state of the system during which the job should be running. For this reason, there is no direct equivalent of the stop on EVENT configuration, or complex method of defining a stop state. The until operator is intended for that purpose.

is equivalent to



Data preservation and migration

Unresolved issues


ComplexEventConfig (last edited 2007-02-21 18:50:33 by scott)