[Bug 974584] Re: Semaphores cannot be created in lxc container

[Launchpad Bug Tracker]

This bug was fixed in the package lxc - 0.7.5-3ubuntu62

---------------
lxc (0.7.5-3ubuntu62) precise-proposed; urgency=low

  * lxc.postrm: support "purge" command (LP: #1029716)
 -- Serge Hallyn <serge.hallyn at ubuntu.com>   Fri, 27 Jul 2012 03:31:39 +0000

** Changed in: lxc (Ubuntu Precise)
       Status: Fix Committed => Fix Released

** Changed in: sysvinit (Ubuntu Precise)
       Status: Fix Committed => Fix Released

-- 
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