On Tue, Jul 17, 2012 at 07:17:25PM +0200, Kurt Roeckx wrote: > On Tue, Jul 17, 2012 at 04:58:14PM +0100, Roger Leigh wrote: > > On Tue, Jul 17, 2012 at 03:41:05PM +0200, Kurt Roeckx wrote: > > > I've set up a schroot of type=directory and pointed directory to > > > the right place, but when I then call schroot to get into that, > > > and then left it, it reguarly fails with: > > > E: 10mount: umount: > > > /var/lib/schroot/mount/i386-sid-8850e601-cd43-4a82-b87c-08a8120619bd/home: > > > device is busy. > > > E: 10mount: (In some cases useful info about processes that use > > > E: 10mount: the device is found by lsof(8) or fuser(1)) > > > E: i386-sid-8850e601-cd43-4a82-b87c-08a8120619bd: Chroot setup failed: > > > stage=setup-stop > > > > What type of filesystem is /home? > > /home is on / and / is ext4.
OK. That is certainly not going to cause problems. The only problems in a simple setup like this were found by phil when using per-process namespaces, when he created a new namespace on the host during the lifetime of the schroot session. This caused busy errors during umounting, because it's still active in the other namespace. It's a remote possibility this might happen to you if you have other (even unrelated) daemons or other processes cloning with CLONE_NEWNS. > > Is there anything running on your system (outside the chroot) which > > has files/directories open inside the chroot? > > Of course I have things running outside the chroot that have files > open in /home. > > But there is nothing that does anything with /var/lib/schroot OK. > > Is there anything > > inside which is running despite the 15killproc script having been > > run? > > Their shouldn't. The only thing I started in the schroot was bash and ls, > no reason for anything to be running there that I started. > > It's reproducible, but I now need to try like 20 times. Other than the CLONE_NEWNS issue, above, my only other suggestion is if there is a process monitoring the filesystem with something like fam/inotify/dnotify which may transiently have a directory open under /var/lib/schroot? This could result in intermittent failures when you just happen to end the session as it's reading a directory. All of these failure scenarios are very difficult for us to work around, because they are happening outside the chroot and outside our control. I would suggest investigating what's causing this by e.g. stopping individual daemons or applications to pin down the culprit. 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
