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

[Julien Viard de Galbert]

On Mon, May 14, 2012 at 09:30:34PM +0100, Roger Leigh wrote:
> 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.
> 
First thanks for your quick answer.

> 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.
> 
I'm not currently using the computer on which I saw the problem and was
planning to actually setup the test before answering you, but I don't
think this is needed because I totally agree with your next sentence:

> 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
> 
From what I've seen it's exactly that, CHROOT_PATH is
CHROOT_MOUNT_LOCATION concatenated with "location".

> 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).
> 
This is where I disagree :)

I would agree if the "do_kill_all" function was doing some call to
"lsof" as I had to do to find out the offending process, but this
function is not doing that. Instead it compares the entry in
"/proc/PID/root/" with its parameter to find process that are run
from within the chroot. So that's why I think the parameter should be
the actual chroot path so CHROOT_PATH.

> 
> 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.
> 

When I first had the issue and was chasing it, I came across #391319
I know it's about 6 years old, it's when the script 15killprocs was
created, and it pointed my investigation to its direction.

But today, I just looked at it again and it seams to me that not
killing process outside the chroot was considered a feature back then:
May I quote message #15:
| [...] If there are open files, we don't
| want to kill anything /outside/ the chroot, which may also be using
| the filesystem.

I guess I should have written more of my analysis of the problem in my
initial bugreport...
But well I hope I made my point of view clearer now :)

> 
> Regards,
> Roger
> 

Best Regards,

Julien VdG

-- 
Julien Viard de Galbert                        <julien at vdg.blogsite.org>
http://silicone.homelinux.org/           <julien at silicone.homelinux.org>
GPG Key ID: D00E52B6                  Published on: hkp://keys.gnupg.net
Key Fingerprint: E312 A31D BEC3 74CC C49E  6D69 8B30 6538 D00E 52B6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20120515/c2f0e396/attachment.pgp>