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/job-serialisation
Upstart is currently a largely parallel system, serialisation is only provided within a single job; it is not possible for one job to delay the starting or stopping of another until it has completed itself. This specification proposes allowing serialisation by waiting for the completion of events before moving on to the next state.
While researching example jobs, it became apparent that there are two common pairing of job events that other jobs will be using. Jobs that depend on another will be started on the started event, because they need it to be running, and will therefore be stopped on the stopping event. The other major kind of jobs are those that believe the other job depends on them; they'll be started on the other's starting event so that they can be running by the time the other is started, and will be stopped by the other's stopped event because they want to be around if there's any possibility the other job is around.
For the first kind of job, we'll almost always want it to be stopped before the job it depends on is allowed to stop. For the second, we'll amost want it to be started before the job that is a dependency on is allowed to start.
While this can be done within the pre-start or pre-stop tasks, e.g. by waiting for initctl emit to complete; it's going to be sufficiently common that it's worth upstart handling this by default.
When installed, tomcat becomes a dependency of the apache web server. It's not possible for apache to run without it; so apache should wait until tomcat is running, before starting.
hal depends on the dbus daemon, maintaining a connection to it. While it can cope with dbus going away, errors maybe left in the log. It would be better if hal were stopped before dbus could stop.
This scope of this specification is limited to the changes necessary to allow for serialisation of jobs.
The starting and stopping events will be serialised.
The started and stopped events will not be changed.
Handling of the serialised events (as defined by EventCompletion) must complete before any further action is performed.
- Failure of the events is ignored.
- These events will be introduced in the documentation later, as specifically serialised events, to avoid people using them without realising that they have this effect.
Instead of job_change_state in init/job.c starting the process directly when entering the starting or stopping states, only the event will be emitted. The job will be in the appropriate state, but with no process running.
Once handling of the event completes, the process will actually be started.
Data preservation and migration
These changes are being made to features that do not yet exist, so while they are not backwards compatible with those features as specified, these should not present a problem.