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
