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

[Roger Leigh]

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?

We do need to support:
- transient sessions created for a single task e.g. build
- sessions which last for a whole "user session" e.g. for virtualising
  a piece of desktop software e.g. 32-bit chroot on 64-bit
- long lived sessions which persist over a long duration (across
  login sessions and reboots)

If that's not possible, maybe we just disable the initscript so that
session recovery doesn't occur under systemd?  Can we retain cleanup
of sessions on shutdown?  This idea won't be tenable if manual
recovery doesn't work.

Given that schroot is setuid, it looks like setuid programs are still
"inside" the user session (whatever that actually is concretely
defined as, since the documentation and "specification" (I use the
word in its loosest possible sense) are extremely poor and
incomplete).

I can't personally going to spend any time on this since I'm not using
systemd and don't plan to, but I would certainly appreciate any
suggestions or patches from anyone who understands exactly what systemd
broke and how it should be fixed, so long as it doesn't compromise
schroot's portability to other platforms.


Kind regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800