[buildd-tools-devel] Bug#749897: Bug#749897: schroot: Can't end session after schroot automatically restored it during boot under systemd

[Mike Hommey]

retitle 749897 Can't end session if daemon starting after a schroot session is created uses a private mount namespace.
tag 749897 - moreinfo
thanks

On Tue, Jul 15, 2014 at 09:48:58PM +0100, Roger Leigh wrote:
> tags 749897 + moreinfo
> 
> On Fri, May 30, 2014 at 10:07:24PM +0900, Mike Hommey wrote:
> > 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.
> 
> Great.  Another utterly simple thing that worked for a decade broken :(
> 
> Does it work if you run "schroot --recover-session -c $session" inside
> a user session?  (with recovery at startup disabled).  Does it work if
> logged in as root outside a user session?
> 
> Not being an expert, I'd be happy to hear any suggestions.  Sounds like
> the ideal solution (if possible) would be to force all schroot mount/umount
> etc. operations to be performed in the global namespace outside the user
> session.  Is that possible?

man setns(2).

Now, looking at it more closely, it actually is not related to systemd.

# readlink /proc/*/ns/mnt | sort | uniq -c
219 mnt:[4026531840]
  1 mnt:[4026531856]
  1 mnt:[4026532315]
  1 mnt:[4026532408]

# ls -l /proc/*/ns/mnt | grep 'mnt:\[4026531856\]'
lrwxrwxrwx 1 root     root     0 Jul 16 08:48 /proc/27/ns/mnt -> mnt:[4026531856]
# ls -l /proc/*/ns/mnt | grep 'mnt:\[4026532315\]'
lrwxrwxrwx 1 colord   colord   0 Jul 16 08:48 /proc/2168/ns/mnt -> mnt:[4026532315]
# ls -l /proc/*/ns/mnt | grep 'mnt:\[4026532408\]'
lrwxrwxrwx 1 root     root     0 Jul 16 08:48 /proc/2176/ns/mnt -> mnt:[4026532408]

# ps -p 27
  PID TTY          TIME CMD
   27 ?        00:00:00 kdevtmpfs
# ps -p 2168
  PID TTY          TIME CMD
 2168 ?        00:00:00 colord
# ps -p 2176
  PID TTY          TIME CMD
 2176 ?        00:00:00 rtkit-daemon

# grep -c schroot /proc/27/mounts
0
# grep -c schroot /proc/2168/mounts
30
# grep -c schroot /proc/2176/mounts
30

If I use the ns_exec program from man setns to go in those two namespaces
and unmount all schroot mount points, then schroot -e works.

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".

Mike