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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
