Differences between revisions 10 and 11
Revision 10 as of 2006-11-30 12:35:04
Size: 2900
Editor: scott
Comment: improve spec (ahem)
Revision 11 as of 2011-08-26 04:10:19
Size: 2900
Editor: localhost
Comment: 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.

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 2011-08-26 04:10:19 by localhost)