From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Pittman Subject: Re: [Devel] [PATCH] Allow signalling container-init Date: Thu, 09 Aug 2007 11:29:06 +1000 Message-ID: <87myx1h4wt.fsf@rimspace.net> References: <20070808234737.GA18334@us.ibm.com> <87vebph6vq.fsf@rimspace.net> <20070809012128.GA16391@sergelap.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20070809012128.GA16391-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org> (Serge E. Hallyn's message of "Wed, 8 Aug 2007 20:21:28 -0500") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Serge E. Hallyn" Cc: Containers , Oleg Nesterov , Pavel Emelianov List-Id: containers.vger.kernel.org "Serge E. Hallyn" writes: > Quoting Daniel Pittman (daniel-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org): >> sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org 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-gyMb1R/nBgM33TBCqt261WVqPpYm49HuKQEueVp/e6I@public.gmane.org http://digital-infrastructure.com.au/