init: respawn detection relies on non-monotonic clock

Bug #389586 reported by Scott James Remnant (Canonical)
4
Affects Status Importance Assigned to Milestone
upstart
Fix Released
High
Scott James Remnant (Canonical)

Bug Description

The respawn detection works by recording the last time that the job was respawned, and then when it is next due to be respawned, seeing if the delta between the two is greater than the respawn interval. The time it uses is obtained from time(NULL), the UNIX seconds since epoch.

This is not safe against changes to the system clock; any change to the system time would be incorrectly either result in jobs being flagged as respawning too fast, or jobs NOT being flagged when they are.

clock_gettime (CLOCK_MONOTONIC) should be used instead, or the code re-engineered completely

Changed in upstart:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Slawomir Czarko (lauchpad-net-sklep) wrote :

Any idea when can this be fixed?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Patches in Palm WebOS apparently fix this, I'm awaiting a response from Palm as to whether they would assign copyright for the patch - otherwise I'll have to reimplement myself later.

Changed in upstart:
status: Triaged → Fix Committed
Revision history for this message
Slawomir Czarko (lauchpad-net-sklep) wrote :

Which revision has this fix?

Changed in upstart:
milestone: none → 0.6.0
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :
Download full text (6.7 KiB)

This has been fixed in Upstart 0.6.0.

0.6.0 2009-07-09 "How appropriate, you fight like a cow"

 * The licence for Upstart has been changed back to version 2 of the
   GNU GPL.

 * D-Bus 1.2.15 is now required, this is the current GIT HEAD
   pending a 1.2.16 release.

 * Configuration paths have changed. Global configuration now
   resides in "/etc/init.conf" while jobs are now configured in
   "/etc/init"

 * Job configuration filenames must now end in ".conf"

 * Default configuration files are now supplied in the "conf"
   sub-directory of the source, and installed into "/etc/init".

   These match the Debian/Ubuntu sysvinit configuration so may
   require some tweaking for other distributions, but provide an
   excellent base.

   The old example-jobs tarballs are deprecated.

 * The D-Bus interface remains unstable, to reflect this the current
   interface name has changed to "com.ubuntu.Upstart0_6" and the
   name of the job and instance interfaces have changed to match.

 * The "EmitEvent" D-Bus method gains a wait argument, when given
   as TRUE (the recommended setting) the method call will be blocked
   until all effects of the event have finished. When FALSE the
   method call will return once the event has been queued.

 * The "Start", "Stop" and "Restart" D-Bus methods of jobs and
   instances gain a similar wait argument.

 * The Upstart D-Bus object now has "version" and "log_priority"
   properties. The former is to obtain the version of the init daemon,
   the latter allows you to obtain and change the logging priority.

 * Job D-Bus objects now have "name", "description", "author" and
   "version" properties to obtain the job name and the contents of
   the equivalent job file fields for the others.

 * Instance D-Bus objects now have "name", "goal", "state" and
   "processes" properties to obtain the instance name, goal, state
   and list of running processes and their pids respectively.

 * The default D-Bus security policy now permits use of the "Get"
   methods by all users, including obtaining values of properties.

 * initctl has been rewritten with functionality more along the
   lines of Upstart 0.3.x than before; since many distributions are
   still shipping 0.3.x the summary of changes for the tool reflects
   both changes from 0.3.x and 0.5.x

 * The global "-p"/"--pid" argument has been dropped, since
   communication is over D-Bus. New "--system" and "--dest" arguments
   have been added to force communication over the system bus, and
   specify the destination, instead of using the private socket (this
   is the default when run as non-root to permit "list" and "status"
   to work for ordinary users).

 * The "-i"/"--id" and "--show-ids" options to commands have been
   dropped since jobs no longer have ids.

 * Since instances may now have names, these will be displayed in
   brackets after the job name when one is present. The output of
   the goal and state are now expressed as "start/running" instead
   of "(start) running" to disambiguate.

 * initctl "start" and "stop" now only output the final state of
   the job, not inte...

Read more...

Changed in upstart:
assignee: nobody → Scott James Remnant (scott)
status: Fix Committed → Fix Released
Revision history for this message
Slawomir Czarko (lauchpad-net-sklep) wrote :

Is this going to be fixed in 0.3.x as well?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 389586] Re: init: respawn detection relies on non-monotonic clock

On Thu, 2009-07-09 at 16:35 +0000, Slawomir Czarko wrote:

> Is this going to be fixed in 0.3.x as well?
>
I think that I would prefer for people to update to 0.6.0, there should
be no reason to stay on the 0.3.x series now.

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Slawomir Czarko (lauchpad-net-sklep) wrote :

0.6.0 was just released yesterday so distros will take some time before switching. Are you planning to backport this to 0.3.x in the mean time?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Fri, 2009-07-10 at 09:44 +0000, Slawomir Czarko wrote:

> 0.6.0 was just released yesterday so distros will take some time before
> switching. Are you planning to backport this to 0.3.x in the mean time?
>
It's the distros that I'm most keen to have updated to 0.6.0 - aside
from a few bug fixes, 0.3.x is really over two years old at this point.

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Slawomir Czarko (lauchpad-net-sklep) wrote :

0.6.0 depends on dbus 1.2.15 but as far as I can see on dbus website the last release is 1.2.14. Is it OK to build upstart 0.6.0 against dbus 1.2.14 or earlier version or will it only work correctly with dbus 1.2.15?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Fri, 2009-07-10 at 11:38 +0000, Slawomir Czarko wrote:

> 0.6.0 depends on dbus 1.2.15 but as far as I can see on dbus website the
> last release is 1.2.14. Is it OK to build upstart 0.6.0 against dbus
> 1.2.14 or earlier version or will it only work correctly with dbus
> 1.2.15?
>
As noted in NEWS, this is current GIT HEAD prior to a 1.2.16 release
(which is due as soon as Colin releases it)

Scott
--
Scott James Remnant
<email address hidden>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.