/dev/shm is not writable inside vivid chroot on trusty host

Bug #1399772 reported by Francis Ginther
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)
Fix Released
Critical
Martin Pitt

Bug Description

This problem is visible on a pool of pbuilder nodes. All of the slaves are amd64 running trusty. I can observe the issue when using pbuilder to mount a vivid chroot. The problem can be recognized by the fact that within the chroot, /dev/shm is not a link to /run/shm. See output below. This problem is only visible on a set of x86 hosts. I also have a set of armhf hosts (with armhf chroots). These armhf boxes do not show the problem.

This is only visible with vivid chroots. Trusty and utopic chroots show /dev/shm as a symlink to /run/shm.

All of the hosts have debootstrap 1.0.59ubuntu0.2. The amd64 nodes are running in openstack VMs, the armhf nodes are running on bare metal.

This appears to be a regression in behavior. The problem is impacting unit test cases in packages being built with the chroots. These test were working in the past, but the exact timeframe for when the problem was first observed is difficult to track down. Possible this has only been the case for about 2 months.

[On the amd64 host:]
$ ls -la /{dev,run}/sh*
lrwxrwxrwx 1 root root 8 Nov 26 21:15 /dev/shm -> /run/shm

/run/shm:
total 0
drwxrwxrwt 2 root root 40 Nov 26 21:19 .
drwxr-xr-x 21 root root 800 Dec 5 17:38 ..

[Inside the amd64 chroot:]
# ls -la /{dev,run}/sh*
/dev/shm:
total 8
drwxr-xr-x 2 root root 4096 Nov 26 21:31 .
drwxr-xr-x 4 root root 4096 Nov 26 21:31 ..

/run/shm:
total 4
drwxrwxrwt 2 root root 40 Dec 5 19:16 .
drwxr-xr-x 5 root root 4096 Nov 26 21:32 ..

[On the armhf host:]
$ ls -la /{dev,run}/sh*
lrwxrwxrwx 1 root root 8 Aug 9 05:08 /dev/shm -> /run/shm

/run/shm:
total 0
drwxrwxrwt 2 root root 40 Aug 9 05:08 .
drwxr-xr-x 17 root root 620 Dec 5 17:37 ..

[Inside the armhf chroot:]
# ls -la /{dev,run}/sh*
lrwxrwxrwx 1 root root 8 Oct 27 13:58 /dev/shm -> /run/shm

/run/shm:
total 4
drwxrwxrwt 2 root root 40 Dec 5 19:16 .
drwxr-xr-x 6 root root 4096 Oct 27 13:59 ..

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: debootstrap 1.0.59ubuntu0.2
ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10
Uname: Linux 3.13.0-40-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
Date: Fri Dec 5 19:14:23 2014
Ec2AMI: ami-00000052
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: production
Ec2InstanceType: m1.jenkins.builder.prod
Ec2Kernel: aki-00000002
Ec2Ramdisk: ari-00000002
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: debootstrap
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Francis Ginther (fginther) wrote :
Revision history for this message
Francis Ginther (fginther) wrote :

Well, this probably isn't debootstrap as I found one of the amd64 pbuilder nodes that shows /dev/shm as a symlink to /run/shm. Both running debootstrap 1.0.59ubuntu0.2. I'm attaching a package comparison between the working system and the failing system.

Revision history for this message
Francis Ginther (fginther) wrote :

"dpgk-l-working.txt" is the system where /dev/shm is a symlink to /run/shm. "dpgk-l-failing.txt" is the system where /dev/shm is a directory.

affects: debootstrap (Ubuntu) → ubuntu
Revision history for this message
Francis Ginther (fginther) wrote :

I created a new set of pbuilder chroots again, the vivid chroots still show that /dev/shm is a directory without global write permissions:

# ls -l /dev|grep shm
drwxr-xr-x 2 root root 4096 Dec 15 21:57 shm

Revision history for this message
Colin Watson (cjwatson) wrote :

This is reproducible with simple debootstraps of utopic vs. vivid. It looks as though a fair bit of relevant code was dropped from initscripts.postinst somewhere along the way, which I suspect is relevant.

affects: ubuntu → sysvinit (Ubuntu)
Steve Langasek (vorlon)
Changed in sysvinit (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti)
Changed in sysvinit (Ubuntu):
status: New → In Progress
milestone: none → ubuntu-15.01
Revision history for this message
Martin Pitt (pitti) wrote :

Directories in a pristine trusty VM after debootstrapping utopic and vivid:

$ ls -ld /{dev,run}/shm /tmp/{utopic,vivid}/{dev,run}/shm
ls: cannot access /tmp/vivid/run/shm: No such file or directory
lrwxrwxrwx 1 root root 8 Dec 18 18:37 /dev/shm -> /run/shm
drwxrwxrwt 2 root root 40 Dec 18 18:37 /run/shm
lrwxrwxrwx 1 root root 8 Dec 18 18:49 /tmp/utopic/dev/shm -> /run/shm
drwxr-xr-x 2 root root 4096 Dec 18 18:49 /tmp/utopic/run/shm
drwxr-xr-x 2 root root 4096 Dec 18 18:50 /tmp/vivid/dev/shm

So I suppose pbuilder takes care of /run/shm by mounting a tmpfs on it or bind-mounting it from the host. As wrong as https://wiki.debian.org/ReleaseGoals/RunDirectory is (and it seems the Debian sysvinit maintainers even have moved away from it, cf. the removed postinst code), it seems we need to go back there at least half way, until pbuilder etc. treat /dev/shm/ as the primary thing, and stop using /run/shm.

So either in vivid we need to create /run/shm/ again and the /dev/shm symlink to it, or at least make /dev/shm/ 1777.

Martin Pitt (pitti)
Changed in sysvinit (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sysvinit - 2.88dsf-53.2ubuntu3

---------------
sysvinit (2.88dsf-53.2ubuntu3) vivid; urgency=medium

  * debian/initscripts.postinst: Create /dev/shm directory with 1777
    permissions, so that chroots stay compatible to what you'd find on a real
    system. (LP: #1399772)
 -- Martin Pitt <email address hidden> Thu, 18 Dec 2014 19:56:07 +0100

Changed in sysvinit (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Olivier Tilloy (osomon) wrote :

I just created a vivid chroot with `pcreate -a amd64 -d vivid vivid-amd64` and I verified that inside it /dev/shm is a directory with permissions "drwxrwxrwt". Thanks Martin!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.