[Bug 974584] Update Released

[Brian Murray]

The verification of this Stable Release Update has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regresssions.

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

Title:
  Semaphores cannot be created in lxc container

Status in Launchpad itself:
  Invalid
Status in “lxc” package in Ubuntu:
  Fix Released
Status in “sysvinit” package in Ubuntu:
  Fix Released
Status in “lxc” source package in Precise:
  Fix Released
Status in “sysvinit” source package in Precise:
  Fix Released
Status in “lxc” source package in Quantal:
  Fix Released
Status in “sysvinit” source package in Quantal:
  Fix Released
Status in “sysvinit” package in Debian:
  Fix Released

Bug description:
  [rational]
  Current initscripts doesn't deal properly with chroots, bind-mounting /run/shm to /dev/shm instead of making the later a symlink to the former.
  LXC has been carrying a workaround for that, sadly the workaround stopped working late in the 12.04 cycle, meaning that an extra chunk of code had to be added to properly fix any broken container before applying the upgrade as any initscripts update would otherwise fail.

  [test case]
  Two things to test:
  1) lxc-create -t ubuntu -n p1
  2) Check that /dev/shm is a symlink to /run/shm in the container

  1) Get an existing container
  2) Update to -proposed
  3) Check that /dev/shm is now a symlink to /run/shm

  [regression potential]
  There's a known risk for applications using shm during the upgrade as the entries will be moved to another file system. As long as all the processes accessing the file keep running, it should be fine, but it won't if another one is spawned as it will try reading it from the new location. A warning is displayed recommending a reboot.

  The rest of the code was already tested with all known scenario and
  should be sufficiently guarded to only apply to the affected systems.

  >>> from multiprocessing import synchronize
  >>> synchronize.Lock()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.6/multiprocessing/synchronize.py", line 117, in __init__
      SemLock.__init__(self, SEMAPHORE, 1, 1)
    File "/usr/lib/python2.6/multiprocessing/synchronize.py", line 49, in __init__
      sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
  OSError: [Errno 38] Function not implemented

  Thanks to hallyn, there's a workaround and a fix: adding this line to the container's fstab will fix the problem:
  none dev/shm tmpfs defaults 0 0

  He is updating the ubuntu template with this change.

  Original bug report description was Launchpad related (celery tests
  fail on parallel testing instances)

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/974584/+subscriptions