[Bug 1438942] Re: Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots

[Tyler Hicks]

I've sent patches to fix this issue to upstream schroot by attaching the
patches to a comment in a related Debian bug. I've linked this bug to
that Debian bug. (https://bugs.debian.org/728096)

** No longer affects: sbuild (Ubuntu)

** Bug watch added: Debian Bug tracker #728096
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096

** Also affects: schroot (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096
   Importance: Unknown
       Status: Unknown

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

Title:
  Host's /dev/shm is mounted over when entering 14.10 and older sbuild
  schroots

Status in schroot package in Ubuntu:
  In Progress
Status in schroot package in Debian:
  Unknown

Bug description:
  Originally reported by Scott Moser:

  https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264/comments/12

  On a Vivid system with schroot 1.6.10-1ubuntu1, the host's /dev/shm is
  mounted over with a new tmpfs instance when entering a 14.10 and older
  schroot. It does not happen when entering a Vivid schroot.

  # Create 14.10 and Vivid sbuild schroots
  $ arch=amd64
  $ for rel in vivid utopic; do mk-sbuild --eatmydata --arch=$arch $rel 2>&1 | tee /tmp/schroot-$rel-$arch.log; done

  # Enter vivid-amd64 sbuild schroot and diff /proc/self/mounts
  $ mounts=/proc/self/mounts
  $ orig=$(mktemp) && cp $mounts $orig && schroot -c vivid-amd64 true; diff -u $orig $mounts

  # Enter utopic-amd64 sbuild schroot and diff /proc/self/mounts
  $ orig=$(mktemp) && cp $mounts $orig && schroot -c utopic-amd64 true; diff -u $orig $mounts
  --- /tmp/tmp.DdnrDnkS2B	2015-03-31 18:19:51.406526006 -0500
  +++ /proc/self/mounts	2015-03-31 18:19:51.818526006 -0500
  @@ -28,3 +28,4 @@
   tmpfs /run/user/108 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=108,gid=117 0 0
   gvfsd-fuse /run/user/108/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=108,group_id=117 0 0
   tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=1000,gid=1000 0 0
  +tmpfs /dev/shm tmpfs rw,relatime 0 0

  # Verify that /proc/self/mounts now contains two /dev/shm mounts
  $ grep /dev/shm $mounts
  tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
  tmpfs /dev/shm tmpfs rw,relatime 0 0

  This causes a problem for programs that keep state in /dev/shm. For
  example, ecryptfs-utils maintains a per-user session counter in
  /dev/shm that is lost when a new tmpfs mount is performed on top of
  the old tmpfs mount. This results in encrypted home directories being
  unmounted when the schroot is tore down.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1438942/+subscriptions