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)
