converted to 1.6 markup
|No differences found!|
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.
Launchpad entry: https://launchpad.net/products/upstart/+spec/jobs-as-states
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.
- 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.