Dave Hansen wrote:
Brainstorming ... what do you think about having a special init process
inside the child to act as a proxy of sorts? It is controlled by the
parent vserver/container, and would not be subject to resource limits.
It would not necessarily need to fork in order to kill other processes
inside the vserver (not subject to resource limits). It could also
continue when the rest of the guest was suspended.
A pid killer would be ineffective against such a process because you
can't kill init.
Well, another approach would be to create a new context which has
visibility over the other container as well as the ability to send
signals to it.
In general, I prefer to think of this as working
with nuclear material via an actuator from behind
a 4" lead wall -- you just do not want to go in
to fix things :)
Where does that lead you? Having a single global pid space which the
admin can see? Or, does a special set of system calls do it well
enough?
I don't like this term "single global pid space". Two containers might
be able to see all processes on the system, one might have a flat
mapping to all PIDs < 64k (or pid_max), one with the XID,PID encoded
bitwise. They are both global pid spaces, but there is no "single" one,
unless that is all you compile in.
Sam.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
