Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot
- Subject: Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot
- From: email@example.com (Martin Pitt)
- Date: Thu, 8 Dec 2016 16:37:58 +0100
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <148016662271.12519.4329301338100249480@localhost> <148014022513.12519.17562392389369543010@localhost>
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
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 Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)