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

[Stéphane Graber]

** Description changed:

+ [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 chroot 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)
+   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)

** Changed in: sysvinit (Ubuntu Precise)
       Status: Triaged => In Progress

-- 
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:
  In Progress
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 chroot 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