[Pkg-sysvinit-devel] Bug#674178: /dev/shm is not set up right in chroot

[Serge Hallyn]

Quoting Roger Leigh (rleigh at codelibre.net):
> > > Hmm, looks like the upload went wrong last night; it was not accepted
> > > for some reason.  I've reuploaded--it's definitely passed through the
> > > upload queue.  In the meantime, you can also get the packages here:
> > > http://people.debian.org/~rleigh
> > > (It's now also in incoming, http://incoming.debian.org/sysvinit_2.88dsf-25.dsc)
> > 
> > Thanks.  That one did NOT result in a leftover mount on $chroot/run/shm,
> > however i got:
> > 
> > Installing new version of config file /etc/default/rcS ...
> > Installing new version of config file /etc/default/tmpfs ...
> > Installing new version of config file /etc/network/if-up.d/mountnfs ...
> > dpkg: error processing initscripts (--install):
> > subprocess installed post-installation script returned error exit status 1
> > dpkg: dependency problems prevent configuration of sysvinit:
> > sysvinit depends on initscripts (>= 2.88dsf-13.3); however:
> > Package initscripts is not configured yet.
> > dpkg: error processing sysvinit (--install):
> > dependency problems - leaving unconfigured
> > Errors were encountered while processing:
> > initscripts
> > sysvinit
> 
> What went wrong with the initscripts postinst configure?  Would it
> be possible to find out where the failure occurred?

Oh, I'm not sure what happened - the sid version didn't do it.  Sure, I
can dig into exactly what happened.  (It takes about an hour every time
to set up the victim VM, I may not get to it until monday)

> > More importantly (this is the root of the problem I started looking into for
> > containers) it leaves the /dev/shm directory.  Since a chroot doesn't usually
> > have a separate /dev, that means that on the next entering of the chroot (or
> > startup of the container) you'll have the devshm tmpfs mounted at /run/shm,
> > and an empty separate directory at /dev/shm.
> 
> I think this is deliberate.  We're a bit stuck here.  Consider that
> it's quite common to bind mount the host /dev into the chroot; mucking

Oh dear.  So then possible scenarios include:

1. simple old host upgrading:  /run/shm doesn't exist, /dev/shm is a mounted dir.

2. new host upgrading without having rebooted after (1): /run/shm is mounted dir, /dev/shm is bind mount of /run/shm.

3. new host upgrading: /run/shm is mounted dir, /dev/shm is symlink.

4. old chroot on old host upgrading with bind mounted /dev:  /run/shm doesn't yet exist, /dev/shm is mounted dir

5. new chroot on old host upgrading with bind mounted /dev:  /run/shm exists, /dev/shm is separate mounted dir

and more...

But,

> around deleting this directory could seriously break the host system.
>
> IIRC this is a deliberate choice.  I'm not sure it's the right choice
> for newly bootstrapped or installed systems though--we should be
> creating a symlink in this case, and I'll be happy to change that
> logic if possible, but for upgrades of chroots it's really not a good
> plan.

Ok, so how about the following:  the block of code which now reads:

=============================
if ischroot; then
        # Symlink /var/run from /run
        # Note var/run is relative
        if compat_link /var/run /run; then
                # Symlink /var/lock from /run/lock
                # Note that it's really /var/run/lock
                compat_link /var/lock /run/lock

                # Symlink /dev/shm from /run/shm
                # Note that it's really /var/run/shm
                compat_link /dev/shm /run/shm
        fi
# Host system, not a chroot.
else
=============================

First, note that during debootstrap, at 'compat_link /var/run /run'
/run and /run/lock already exist.  So how about if we create /run/shm
(if it doesn't yet exist), and symlink /dev/shm from /run/shm only
if /dev/shm doesn't yet exist?  We don't change the !isroot case.
So it would look like:

=============================
if ischroot; then
        # Symlink /var/run from /run
        # Note var/run is relative
        if compat_link /var/run /run; then
                # Symlink /var/lock from /run/lock
                # Note that it's really /var/run/lock
                compat_link /var/lock /run/lock

                # Symlink /dev/shm from /run/shm
                # Note that it's really /var/run/shm
		[ ! -d /run/shm ] && mkdir /run/shm
		if [ ! mountpoint -q /dev ]; then
			[ ! -d /dev/shm ] && compat_link /run/shm /dev/shm
		else
			compat_link /dev/shm /run/shm
		fi
        fi
# Host system, not a chroot.
else
=============================

So if the chroot has /dev/ bind-mounted from the host, assume they
always will, and will want /run/shm as a symlink to /dev/shm.

Otherwise if /dev/shm exists, leave it alone, because we're definately
not in debootstrap.

Otherwise, assume /dev and /run won't get cleaned up at 'shutdown'
(chroot exit) so set up *exactly* what we want to see as the end
result: /dev/shm as a symbolic link to /run/shm.

> For systems using udev, this is a non-issue.  But finding out what
> creates /dev/shm otherwise would be useful.  It looks like it's the
> initscripts postinst, but I'm not sure if it's the only place.  And

If you do debootstrap --foreign sid sid, then strace -f chroot sid
debootstrap/debootstrap --second-stage, then wade through tons of
output :), initscripts.postinst is in fact the only place it is
created.  At least during debootstrap.  (During startup, it'd be
different in debian and ubuntu anyway...)

> even then, it's usually run when udev is active, so won't affect the
> base /dev.

thanks,
-serge