Your message dated Mon, 9 Jan 2017 18:46:25 +0100
with message-id <[email protected]>
and subject line Re: Bug#749897: [buildd-tools-devel] Bug#749897: schroot: 
Can't end session after schroot automatically restored it during boot under 
systemd
has caused the Debian Bug report #749897,
regarding Can't end session if daemon starting after a schroot session is 
created uses a private mount namespace.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
749897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749897
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: schroot
Version: 1.6.10-1+b1
Severity: important

So, I had three schroot sessions active and at some point, there was a reboot
involved. I don't remember if it was a hard reboot or a soft reboot, because
it was actually a while ago, but it doesn't matter anyways.

So, after a while, i figured that it made no sense to keep all those schroot
mount points around, so I asked schroot to end the three sessions. Which it
happily did, until it stopped on a EBUSY error while rmdir'ing the root
mount point in /var/lib/schroot/mount/.

As far as I can tell, the reason why this happens is that the user session
does the schroot -e runs in a mount namespace that is not the global mount
namespace, thanks to systemd. And the schroot restore script at boot most
likely runs in the global mount namespace. So, when schroot -e does its stuff,
all it's doing is unmounting the bind mounts in the user namespace, but those
bind mounts are still active in the global mount namespace. Then rmdir fails
because of that.

Rebooting without systemd allowed schroot -e to do its job properly.

Mike


-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.55.0       1.55.0+dfsg-1
ii  libboost-iostreams1.55.0        1.55.0+dfsg-1
ii  libboost-program-options1.55.0  1.55.0+dfsg-1
ii  libboost-regex1.55.0            1.55.0+dfsg-1
ii  libboost-system1.55.0           1.55.0+dfsg-1
ii  libc6                           2.18-7
ii  libgcc1                         1:4.9.0-4
ii  libpam0g                        1.1.8-3
ii  libstdc++6                      4.9.0-4
ii  libuuid1                        2.20.1-5.7
ii  schroot-common                  1.6.10-1

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-modules  <none>
ii  btrfs-tools                     3.14.1-1
ii  debootstrap                     1.0.60
ii  lvm2                            2.02.106-1
pn  qemu-user-static                <none>

-- Configuration Files:
/etc/schroot/default/fstab changed [not included]

-- no debconf information

--- End Message ---
--- Begin Message ---
On Wed, 16 Jul 2014, Mike Hommey wrote:
> So, it turns out the problem is not "systemd uses a different namespace"
> as I originally thought, but "if daemons starting after a schroot
> session starts uses its own mount namespace, it prevents schroot -e from
> working".

I can't reproduce this any longer neither with a manual operation (using
"unshare --mount bash" to try to lock a mount point) nor with schroot
on a current sid system with linux 4.8.15-2.

I guess that some issues got fixed at the kernel level. I also merged
multiple changes in 1.6.10-3 that help with cleaning up old sessions
(in particular it now identifies correctly processes running in the
chroot).

Feel free to try it out and to report back any remaining problem.

Thank you.

PS: Roger, you should really consider merging all the changes
that we have in debian/patches/:
https://anonscm.debian.org/cgit/buildd-tools/schroot.git/tree/debian/patches
I believe they are sane.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

--- End Message ---

Reply via email to