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 basic operations on a job of start and stop are already atomic in the sense that they can be repeated in any order, and only the last one issued has any effect. This specification proposes extending their atomicity so that their side-effects such as environment they provide to a job are also atomic based around the commands.


Atomicity is one of the keystones to reliable and predictable operation. If none of the side-effects of all possible operations of Upstart are unexpected then users will be inherently more trusting of it. Further specifications such as ExpandEventVariables rely on a predictable environment for a job, which is provided by the start command. That environment needs to be set for all processes of the job, including stop processes, even if the job has been restarted with a different environment in the meantime.

Use cases


This scope of this specification is limited to matters of atomicity and side-effects of the start and stop requests, which while including the introduction of a "job environment" does not extend to using that environment.



Data preservation and migration

These changes alter the blocking behaviour of the start and stop commands when interrupted by another command; the previous semantics were never documented, so nobody should be relying on them yet.

JobAtomicity (last edited 2008-03-03 01:59:14 by scott)