[buildd-tools-devel] Bug#672113: Bug#672113: schroot: 15killprocs does not check the right directory

[Roger Leigh]

On Tue, May 08, 2012 at 04:52:32PM +0200, Julien Viard de Galbert wrote:
> While using sbuild with a file schroot configuration I noticed that
> sometimes the session would not close. It appeared that some daemon
> was still running and keeping the filesystem busy.
> 
> I'm using a tar with a toplevel directory containing the actual chroot
> content. My configuration looks like that:
> ....
> type=file
> file=/path/to/file.tar
> location=/squeeze
> 
> Adding some debugging to 15killprocs I noticed that it misses the 
> location part. So I tried the following change and it seams to fix it
> for me.
> 
> diff --git a/etc/setup.d/15killprocs b/etc/setup.d/15killprocs
> index 3b679f5..7927ee7 100755
> --- a/etc/setup.d/15killprocs
> +++ b/etc/setup.d/15killprocs
> @@ -84,5 +84,5 @@ do_kill_all()
>  }
>  
>  if [ $STAGE = "setup-recover" ] || [ $STAGE = "setup-stop" ]; then
> -    do_kill_all "$CHROOT_MOUNT_LOCATION"
> +    do_kill_all "$CHROOT_PATH"
>  fi
> 
> 
> Please double check that the change is correct and consider including it
> in a later release.

I'm not yet totally sure this is correct.  For one of the chroots
which fails, please could you run "schroot -v" and report what the
values of CHROOT_MOUNT_LOCATION and CHROOT_PATH are when the
setup scripts run on ending the session.

For me, they are always identical, with LOCATION added to CHROOT_PATH
if you have location=xxx in your configuration:

I: 99check: CHROOT_MOUNT_LOCATION=/var/lib/schroot/mount/sid-file-ca2422b1-ce8b-4b91-9141-efc50cce55a9
I: 99check: CHROOT_PATH=/var/lib/schroot/mount/sid-file-ca2422b1-ce8b-4b91-9141-efc50cce55a9/sid

In this case CHROOT_MOUNT_LOCATION is actually better, since it not
only /includes/ CHROOT_PATH in the checks, it also will kill processes
which are outside the chroot but which would cause the umount to
fail (not for file, but certainly for lvm-snapshot and other related
types).


So in summary, I'm confused why the existing logic is not working for
you given that it's actually encompassing (or should be encompassing)
CHROOT_PATH.  If it turns out this assumption is incorrect (and the
above check will be invaluable in determining that), we can change it
to maybe use either CHROOT_PATH or check both to be extra careful.


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