Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot

Johannes Schauer josch at debian.org
Sat Nov 26 06:03:45 UTC 2016


Quoting Johannes Schauer (2016-11-16 16:32:05)
> Quoting Martin Pitt (2016-11-16 16:17:29)
> > Johannes Schauer [2016-11-16 14:13 +0100]:
> > > I have another autopkgtest-specific question. Currently, when using this
> > > code with sbuild and I hit Ctrl+C to send a SIGINT, it appears as if
> > > autopkgtest would immediately call hook_cleanup(). Can that be? How do I
> > > prevent that from happening? It only happens with my uchroot backend and
> > > not any other, so I'm probably doing something wrong. Trapping SIGINT in
> > > the shell script doesn't seem to have any effect.
> > 
> > Right, lib/VirtSubproc.py does that in prepare(). The idea was that ^C
> > would cleanly shut down the virt runner, then the frontend
> > (autopkgtest) would notice and do its cleanup part.
> > 
> > How is calling hook_cleanup() not working/not enough for uchroot? We can
> > certainly make that more flexible if needed.
> Then I still don't understand something. In sbuild, when I hit ^C, the
> autopkgtest schroot backend does not seem to get closed immediately because
> sbuild is still doing some cleanup stuff before sending the "close" command to
> autopkgtest.
> But with the autopkgtest uchroot backend, the hook_cleanup() seems to get
> immediately called after my ^C, thus the cleanup code will fail and the "close"
> command will be futile because the autopkgtest pipe does not even exist anymore
> at that point.
> So I don't understand this difference in behaviour.

I think I got it now.

So if I use sbuild with the autopkgtest schroot backend, and then press Ctrl+C
during dpkg-buildpackage, the following will happen:

 - the hook_cleanup() of autopkgtest-virt-schroot is called
 - schroot is unable to close the session because it cannot unmount stuff that
   is still used by sbuild. It thus sleeps for one second.
 - sbuild starts cleaning up some stuff... time passes...
 - schroot tries again to close the session and fails again for the same
   reason. Waits another second...
 - sbuild does some more things, finally releasing its last use of stuff inside
   the chroot and sends an explicit "close" to autopkgtest
 - schroot tries again to close the session - this time succeeds

With the uchroot autopkgtest backend, hook_cleanup() is also called
immediately.  But in contrast to the schroot autopkgtest backend, the
hook_cleanup() will immediately try wiping the whole rootfs and succeed in
doing so. This in turn will lead to further cleanup actions by sbuild after a
failed build to fail because the chroot already became unusable.

I don't know what the best course of action here is. Should sbuild expect that
after the user presses Ctrl+C, the autopkgtest backend takes care to completely
shut down the backend by itself? I don't think this is a viable option because
the autopkgtest backend used by sbuild might be one that carries over changes
made by sbuild to the next session. And in that cases, the session must not
just close under sbuild's feet but sbuild must be given the chance to clean up
after itself after the user cancelled the build with Ctrl+C.

Is there an existing way that would allow me to kill a job I run via
autopkgtest (after the user pressed Ctrl+C) which does *not* switch off the
whole session but allows sbuild to do its cleanup duties and then explicitly
send the "close" itself after it's done?


cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161126/09663c84/attachment.sig>

More information about the autopkgtest-devel mailing list