Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot
Martin Pitt
mpitt at debian.org
Thu Dec 8 15:37:58 UTC 2016
Hello Johannes,
Johannes Schauer [2016-11-26 6:03 +0000]:
> 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.
Thanks for figuring that out. Indeed the trouble stems from the fact
that there are two different entities trying to control/own the
schroot session -- sbuild and autopkgtest.
I don't think that autopkgtest's schroot runner is at all appropriate
for this -- sbuild already creates the chroot and wants to clean it
up, and autopkgtest shouldn't -- autopkgtest should also not revert
the testbed (in case the test requests it). My recommendation is to
use the chroot runner for that, which doesn't have the "revert"
capability and thus neither the SIGINT nor the "accidental revert" can
happen.
Of course the chroot runner cannot run a lot of tests, but this would
already be true with this approach anyway.
Johannes Schauer [2016-11-26 13:23 +0000]:
> 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)
sbuild could call it through setsid to land in a new process group.
But as I said before that would be a poor workaround -- using the
chroot backend is the correct thing there IMHO.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
More information about the autopkgtest-devel
mailing list