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

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2016-11-26 06:03:45)
> 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?

I think I gathered some more insight. Once Crtl+C is pressed, the terminal
sends SIGINT to all processes in the current process group. This includes
autopkgtest. So as far as I understand it, the only way not to let autopkgtest
receive the SIGINT would be to let autopkgtest not be part of the process group
that sbuild is part of.

Once autopkgtest receives the SIGINT it will call the cleanup handler which in
case of uchroot tries to recursively remove the unpack directory immediately.
At the same time, sbuild will try to run some cleanup jobs. These will fail
because significant parts of the rootfs might already have been removed. At the
same time, recursively removing the rootfs will also fail because the jobs run
by sbuild will still be using files inside the rootfs as mount points.

In the current situation, there is no way for sbuild to know that it should not
try running anything through the autopkgtest backend. There is no way for
sbuild to know that the backend is currently cleaned up. And lastly, there is
no way for sbuild to know that it doesn't have to send the "close" command
anymore.

So I see the following ways to solve this problem:

 - somehow prevent autopkgtest from receiving the SIGINT (I don't know yet
   exactly how to achieve that)
 - implement a mechanism that allows sbuild to tell autopkgtest to ignore
   SIGINT
 - implement a mechanism that allows sbuild to retrieve the current status of
   the backend such that it doesn't try starting jobs on a backend that is
   currently clean up. But this is suboptimal because these cleanup options by
   sbuild might be necessary depending on the autopkgtest backend.

Thanks!

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/96682ab0/attachment.sig>