Differences between revisions 9 and 10
Revision 9 as of 2006-11-29 16:17:21
Size: 2735
Editor: scott
Comment: fix respawning
Revision 10 as of 2006-11-30 12:35:04
Size: 2900
Editor: scott
Comment: improve spec (ahem)
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
 * Events will not be generated for every state change, instead they will only be generated at key points:
  * `starting` when the goal is set to '''start'''
  * `started` when the state reaches '''running'''
  * `stopping` when the goal is set to '''stop'''
  * `stopped` when the state reaches '''waiting'''
 * Events will not be generated for each state change, instead they will be generated at key points that other jobs would wish to know about.

 * The `starting` event will be generated before the job begins to start.
 * The `started` event will be generated once the job is running normally.
 * The `stopping` event will be generated before the job begins to stop.
 * The `stopped` event will be generated once the job has stopped.
Line 38: Line 39:
 * Respawning generates a `stopping` event followed by a `stopped` and then a `starting` event, as if the service had been restarted.  * Respawning will not generate a special set of events, instead it will generate the same sequence as a restart: `stopping`, `starting` and then `started`.
Line 48: Line 49:
The name of `event` variable will be fixed, and not include the job name. The job name will be included as the first argument to this variable. The name of `event` variable will be set according to the state, and will not include the job name. Instead the job name will be passed as the first argument to this event.
Line 50: Line 51:
Events will not be emitted at every state change, but only at those which are meaningful. Intermediate states that do not emit events will leave this variable as `NULL`.

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.

Summary

Events emitted as part of a job state change are currently named after the job, with a suffix indicating the new state. An additional event is emitted directly named after the job. This specification proposes changing the set of events to fixed names, with the job as an argument, and removing the job event entirely.

Rationale

The current names mean that the namespace of jobs and events is shared, which not only causes problems such as the control-alt-delete bug, but also causes great user confusion.

Use cases

  • A user wants a script to run when a block device is added; they create /etc/event.d/block-device-added. This not only doesn't actually get run, but once they add the required hook, it causes problems for every other script as well.

Scope

The scope of this specification is limited to the set of events generated by the current state machine, it does not propose any alterations to the state machine.

Design

  • The job event will be removed entirely; other jobs should refer to which state of that job they are expecting, which makes things somewhat clearer.
  • Events will not be generated for each state change, instead they will be generated at key points that other jobs would wish to know about.
  • The starting event will be generated before the job begins to start.

  • The started event will be generated once the job is running normally.

  • The stopping event will be generated before the job begins to stop.

  • The stopped event will be generated once the job has stopped.

  • They will receive the job name as the first position argument.
    on stopped apache
  • Respawning will not generate a special set of events, instead it will generate the same sequence as a restart: stopping, starting and then started.

Implementation

Code

The changes are limited to job_change_state in init/job.c.

The job_event variable and use of it will be removed entirely.

The name of event variable will be set according to the state, and will not include the job name. Instead the job name will be passed as the first argument to this event.

Intermediate states that do not emit events will leave this variable as NULL.

Data preservation and migration

These changes are not backwards compatible, almost all existing jobs will need changing. No migration plan is anticipated at this point in the development cycle.


CategorySpec

JobEvents (last edited 2006-11-30 12:35:04 by scott)