[ANNOUNCE] upstart 0.3.5 released
Scott James Remnant
scott at netsplit.com
Sat Feb 10 22:01:12 GMT 2007
This release implements just about everything that was decided while at
Google in November (but not what was decided at the Thai place). As
such there's a lot of changes here, and you're well advised to read the
NEWS for the worst of them.
There's a few things left for the 0.3 series, some are planned here:
https://launchpad.net/products/upstart/+milestone/0.3
And some are still only noted in the TODO file.
A new examples jobs (3) has been released with this version.
* Serialisation of job state between upstart processes is disabled;
though upstart will still re-exec itself when sent the TERM
signal, the new copy will not have any of the state of the old.
This will be restored in a later release.
* WARNING: if you have any job declared "console owner" which is
run by the "stalled" event, comment out the "start on" stanza
before sending the TERM signal -- otherwise the newly started
process will start that job, which will kill your running X
server.
* logd and the "console logged" (default) option are currently
disabled, pending large-scale changes to the way that this
works.
* Job scripts have been renamed; "start" to "pre-start" and
"stop" to "pre-stop".
* A new "post-start" script has been added, it's run after the
main process has been started and the "started" event is not
emitted until it finished.
* A new "pre-stop" script has also been added, it's run when a
request or event comes in to stop a job, before the "stopping"
event is emitted and before the job is killed. If this restarts
the job, it will not be stopped.
* Job processes now have an UPSTART_JOB environment variable
containing the name of the job.
* initctl start, stop and status will default to using UPSTART_JOB
if no arguments are given. Therefore you can just put "stop"
or "start" into a job script.
* Where a job was started or stopped by an event, the processes
now have an UPSTART_EVENT environment variable containing the
name of the event.
* Events may now have arguments and environment variables attached,
these can be specified with initctl, e.g.
# initctl emit network-interface-up eth0 -eADDR=00:11:22:33:44:55:66
* These arguments can be matched in the job by placing them after
the event name for the "start on" or "stop on" stanzas:
start on network-interface-up eth*
Additional arguments in the event are assumed to match if not
specified in the job definition, and wildcards may be used within
the job definition as shown above.
* The arguments are also passed to the script of any job started or
stopped by this event as positional arguments, and the environment
variables are placed into the environment of the job.
* The set of events emitted due to a job state change have been
completely changed. The new events are as follows:
started: this is emitted once the job is running and ready, and
receives the job name as an argument.
stopped: this is emitted once the job has been fully stopped. As
well as the job name, if the job terminated normally it will have
the "ok" argument; otherwise it will have the "failed" argument
followed by the name of the script that failed ("running" for the
main job) and either an EXIT_STATUS or EXIT_SIGNAL environemtn
variable indicating why it failed.
starting: this is emitted before the job is started (before even
the pre-start script is run). Arguments are as "started". The
job will not be started until this event has finished.
stopping: this is emitted before the job is stopped (but after th
pre-stop script is run). Arguments are as "stopped". The job will
not be stopped until this event has finished.
These events can be usefully combined as follows.
If the "hal" job requires "dbus" to be running, and "hal" must be
stopped before "dbus" may stop:
start on started dbus
stop on stopping dbus
If the "tomcat" job believes that it must be running before "apache"
can run, and should not be stopped until "apache" has been stopped:
start on starting apache
stop on stopped apache
* The event named for the job has been completely removed; thus
jobs and events no longer share a namespace.
* Jobs have goals to reach; for a task (the default), the goal is
to go from stopped, to started and back to stopped again. This
means that when used for the "starting" or "stopping" event, the
entire task has to complete before the referenced job can actually
be started or stopped.
Services will normally only want the goal to be to go from stopped
to started; thus when used in "starting" in the example above, the
referenced job can be started once the service has been started
(and not stopped again). A service is defined by specifying either
"respawn" or "service" in the definition.
* The list of exit codes that determine whether the main process
failed or succeeded can be specified by the "normalexit"
configuration stanza. The arguments to this stanza can be exit
codes or signal names, e.g.
normalexit 1 99 100 INT QUIT
Zero is implied in the list, unless the job is marked "respawn"
since for those jobs, this is the list of exit codes and signals
that cause the job to be not respawned.
* There is no longer a respawning state, or "respawn script". Jobs
will instead be stopped and started through the same scripts.
* Jobs marked with the "instance" stanza can be started multiple
times; each time they are started, a new instance is created.
* If any job whose goal is changed by an event fail to reach their
new goal, a further "EVENT-NAME/failed" event will be emitted once
the event has finished being handled.
This can be used to emit, for example, a "path-unmounting" event
and to not proceed to "path-unmounted" unless it succeeds.
* initctl emit will block until the event has been handled; it will
also output job status information for any job changed by the event
and terminate with an exit status of 1 if any of those jobs failed
to reach their new goal.
* The set of events emitted by the "telinit" compatibility command
have been changed. It now only emits a single "runlevel" event,
and supplies the new runlevel as an argument to it.
You should change job files that use:
start on runlevel-2
to use the following:
start on runlevel 2
This means also that "stop on runlevel" would stop the job on
any runlevel change.
* Neither the "telinit" nor "shutdown" commands now emit a
"shutdown" event, in fact, this event has been removed altogether.
"shutdown" now simply emits the appropriate runlevel event;
the -H and -P arguments set the INIT_HALT variable in the
environment of that event, just as it does in sysvinit.
* Normal output from initctl, etc. is no longer prefixed "initctl:"
* The "ctrlaltdel" event has been renamed to "control-alt-delete".
The tarball can be found here:
http://upstart.ubuntu.com/download/
For more information on upstart:
http://upstart.ubuntu.com/
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20070210/3e2baa47/attachment.pgp
More information about the upstart-devel
mailing list