[Bug 1124384] Re: Configuration reload clears event that others jobs may be waiting on

[Dmitrijs Ledkovs]

ppa:xnox/backports has the updated upstart package that has the
following fixes:

* reload configuration always works and all events are preserved
* the postinst script was modified to not execute stateful re-exec if runlevel 2 has not been reached yet

The reason for the latter, is that we still loose events that are
blocking jobs that are not running yet across the stateful re-exec,
because EventJobOperators (aka start_on & stop_on conditions) are not
serialised to include progress information w.r.t. their states (e.g.
TRUE or FALSE for each condition to tell apart if it has fired or not
yet).

The above fixes allow to always run reload-configuration, including early boot.
And safeguard against automatic re-execution if upstart package is upgraded during early boot.

To fix stateful re-execution in early boot, we need to serialise all
objects used by upstart which upstream has avoided to do so far. Also
it's questionable if stateful re-execution in early boot is a desired
requirement.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1124384

Title:
  Configuration reload clears event that others jobs may be waiting on

Status in “cloud-init” package in Ubuntu:
  Confirmed
Status in “upstart” package in Ubuntu:
  Confirmed

Bug description:
  Under bug 1080841 we made cloud-init invoke 'initctl reload-
  configuration' after it wrote a upstart job.  This was necessary
  because inotify is not supported on all filesystems (overlayfs being
  the one of most current interst).

  This seems to be causing upstart some pain, and resulting in cloud-
  final (and 'rc') not being run.

  Easy user-data to reproduce the problem is:

  #cloud-config-archive
  - content: |
     #cloud-boothook
     #!/bin/sh
     touch /run/cloud-init-upstart-reload  # hack, see trunk commit 783
  - content: |
     #!/bin/sh
     echo "==== $(date -R): user-script run ===" | tee /run/user-script.log
  - content: |
     #upstart-job
     description "a test upstart job"
     start on stopped rc RUNLEVEL=[2345]
     console output
     task
     script
     echo "==== $(date -R): upstart job run ===" | tee /run/upstart-job.log
     end script

  You should (and do on quantal) end up with 2 files written to /run.

  I've verified that the same behavior is true on quantal.  If you
  change cloud-init to notify upstart about a job immediately after it
  writes it, then quantal's upstart gets confused also.

  Related bugs:
   * bug 1080841: should reload configuration if an upstart job is added
   * bug 1103881: cloud-final is never executed if upstart is upgraded during initialization of the image

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1124384/+subscriptions