[buildd-tools-devel] Bug#681884: Bug#681884: Bug#681884: schroot: Does not always clean up after itself.

[Roger Leigh]

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