[buildd-tools-devel] Bug#829125: schroot: schroot doesn't clean up its bind mounts if used concurrently

[Roger Leigh]

On 30/06/2016 18:02, Dima Kogan wrote:

> Then I enter a schroot:
>
>   $ schroot -c xxx zsh

> Then with this schroot open, I enter it again from a different terminal:
>
>   $ schroot -c xxx zsh
>
>   $ [ in chroot. again. ]
>
> Looking at the mounts, I now see this:
>   devpts on /run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

>   devpts on /run/schroot/mount/xxx-aeef8a02-8d83-4159-9916-75597e00b42d/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
>   devpts on /run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

> So this is a bug. /dev/pts shouldn't have been mounted a second time,
> especially not with the first UUID.
>
> Now I go back to the first schroot, and exit it.
>
>   $ exit
>   E: 10mount: umount: /run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts: target is busy
>   E: 10mount:         (In some cases useful info about processes that
>   E: 10mount:          use the device is found by lsof(8) or fuser(1).)
>   E: xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15: Chroot setup failed: stage=setup-stop
>
> This is a bug, but maybe it makes some sense given what we saw before. The
> second chroot mounted /dev/pts a second time, so it maybe looked busy.
> However if I look at what is still mounted at this point, I see that
> NOTHING got cleaned up

[...]
> These are the UUIDs from the first schroot (the second one we exited).
> So exiting the first schroot cleaned up the mounts from the SECOND
> schroot, but left its own ones alone. This is a bug too.
>
> Hopefully this is helpful. Thanks!

While I don't have a concrete solution to hand, some thoughts:

Are you running systemd?
Does the problem occur when you run sysvinit?
Have you altered any of the setup scripts to do rbind in place of bind? 
(not that this should be a problem; we only removed it because of 
systemd breaking it with autofs on /dev mountpoints)

Can you reproduce this by hand by starting a session, then creating a 
temporary directory and bind mounting the same stuff into it?  That is, 
to recreate the 10mount setup script actions step by step.

My suspicion here is that systemd is changing the mount behaviour and 
that you're getting this erroneous mount as a side effect.  The point of 
the above test is to check whether this is a schroot issue or a more 
general problem with mount(8).  Since schroot isn't doing anything more 
than a series of mount invocations in a shell script and mount helper, 
it's unlikely to cause bizarre side effects in and of itself.


Regards,
Roger