Differences between revisions 1 and 2
Revision 1 as of 2006-11-24 14:14:40
Size: 2195
Editor: scott
Comment: write spec
Revision 2 as of 2006-11-29 14:11:42
Size: 2214
Editor: scott
Comment: Tweak spec
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
start on start networking
stop on stop networking
start on started networking
stop on stopped networking
Line 43: Line 43:
This is backwards compatible with previous behaviour. These changes are backwards compatible with the previous behaviour.

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.


Jobs must currently define either a binary to execute or a shell script to run. This specification proposes removing that restriction so that jobs may be used to indicate states in the system.


There are many cases where being able to define complex states to be re-used by other jobs is useful, by far the most elegant method of doing this is to use the existing job syntax. This not only lets us use a process-less job as a state, but even allows us to define script to be run when entering and leaving that state.

Use cases

  • The multi-user state can be defined as a job, started and stopped by a complex series of events. Other jobs can use the multi-user job events.


This specification is largely informational, and limited to adding the concept of a state to the existing concepts of task and service.


A job without either an exec or script stanza will be considered to define a state. It will remain in the running state until it's stopped, and will otherwise behave exactly like a job.

Semantically we will use the goal of the job to define whether the state is true or not. This allows for other jobs to use syntax such as:

  • start on started networking
    stop on stopped networking



The primary change is to init/cfgfile.c, removing the restriction that exec or script must be specified for a job.

The assertion that this is true must be removed from job_change_state in init/job.c, no other modification is required as this will leave the job in the JOB_RUNNING state if neither is specified.

Data preservation and migration

These changes are backwards compatible with the previous behaviour.


JobsAsStates (last edited 2006-11-29 14:11:42 by scott)