"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > Quoting Daniel Pittman (daniel@xxxxxxxxxxxx): >> sukadev@xxxxxxxxxx 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 limitation. Regards, Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707 email: contact@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx http://digital-infrastructure.com.au/ _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers