[Bug 1124384] Re: reload-configuration can confuse upstart

Scott Moser smoser at ubuntu.com
Wed Apr 3 21:55:08 UTC 2013


Ok, another recreate that is possibly simpler to debug.  Below, we
create 2 jobs, one invokes reload-configuration, the other just writes
something to /run.  We add those jobs to a pristine raring container,
start it, and expect them to run.  Only the first will run. I've
explicitly ran 'start console' from the first so you can log in,
otherwise you wont get a getty, so you can't log in to look around.

cat <<"EOF" | tee job1.conf
description "invoke reload for fun"
start on filesystem
console output
task
script
  read x y < /proc/uptime
  cmd="initctl reload-configuration"
  (
  echo "==== up $x: running $cmd ===" 
  initctl reload-configuration
  echo "got $?"
  ) 2>&1 | tee /run/job1.log
  sh -c 'sleep 5; start console' &
end script
EOF

cat <<"EOF" | tee job2.conf
description "do something around rc.local"
start on stopped rc RUNLEVEL=[2345] 
console output
task
script
  read x y < /proc/uptime
  echo "==== up $x: touching /run/did-something ===" | tee /run/job2.log
  echo "$x" > /run/did-something
end script
EOF

# precise base
sudo apt-get install lxc
sname="raring-amd64-source"
cname="raring-amd64"

sudo lxc-create -n raring-amd64-source -t ubuntu -- --arch=amd64 raring
sudo lxc-clone -o $sname -n $cname
sudo cp job1.conf job2.conf /var/lib/lxc/$cname/rootfs/etc/init/
sudo lxc-start -n  $cname

## now log in as 'ubuntu'.  You *should* see a file /run/did-something.

-- 
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:
  reload-configuration can confuse upstart

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




More information about the foundations-bugs mailing list