Jochen Sprickerhof writes ("Re: Bug#1094635: /usr/bin/autopkgtest-virt-unshare:
processes not killed by close"):
> Note that autopkgtest-virt-unshare does not open some session and the
> unshare syscall only changes the user namespaces for the inside
> processes. Thus running unshare in another terminal is completely
> unrelated to the autopkgtest-virt-unshare except that both share the
> same chroot directory in /tmp/tmp_8rqn1g5.
Yes, I'm aware of this. I regard this as an aspect of the
implementation strategy.
> This sounds like a x/y problem, can you describe why you are doing
> this?
I want to use unshare to contain a multi-process task which might take
an unreasonable length of time and need to be timed out. (Indeed, as
autopkgtest might want to.)
As background:
The purpose of the autopkgtest-virt-* API is to allow an application
(such as autopkgtest) to run code in a controlled and resettble
environment. In the case of autopkgtest that is tests, but other
callers will be using it for other purposes.
The precise semantics aren't well-defined by the autopkgtest virt
protocol spec (which I wrote). It says only "virtualisation
facilities". The semantics can be further defined and extended by the
server advertising capabilities, eg "revert-full-system".
This bug is a request for autopkgtest-virt-unshare to have the
capacity to kill "escaped" processes, when the testbed is closed.
I think that behaviour would makes sense, perhaps even as a default.
After all, the actual chroot is deleted, so any processes which remain
have an empty root fs. Leftover processes are possibly broken in
other ways too.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
