[Devel] [PATCH] Allow signalling container-init

Daniel Pittman daniel at rimspace.net
Wed Aug 8 18:29:06 PDT 2007

"Serge E. Hallyn" <serue at us.ibm.com> writes:
> Quoting Daniel Pittman (daniel at rimspace.net):
>> sukadev at us.ibm.com writes:


>> > TODO:	Ideally we should allow killing the container-init only from
>> > 	ancestor containers and prevent it being killed from that or
>> > 	descendant containers.  But that is a more complex change and
>> > 	will be addressed by a follow-on patch. For now allow the
>> > 	container-init to be terminated by any process with sufficient
>> > 	privileges.
>> This will break, as far as I can see, by allowing the container root to
>> send signals to init that it doesn't expect.
> Yes, in the end what we want is for a container init to receive
> 	1. all signals from a (authorized) process in a parent
> 	   pid namespace.
> 	2. for signals sent from inside it's pid namespace, only
> 	   exactly those signals for which it has installed a
> 	   custom signal handler, no others.
> In other words to a process in an ancestor pid namespace, the init of a
> container is like any other process.  To a process inside the namespace
> for which it is init, it is as /sbin/init is to the system now.

That makes sense.

> Actually achieving that without affecting performance for all
> signalers is nontrivial.  The current patchset is complex enough that
> I'd like to see us settle on non-optimal semantics for now, and once
> these patches have settled implement the ideal signaling.

I appreciate that.  I figured to make you aware that this will make it
impossible to run upstart and, probably, other versions of init in your
container as expected.

Since this was a somewhat subtle bug to track down it is, I think, work
documenting so that people trying to use this code are aware of the

Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au

More information about the Containers mailing list