Re: [PATCH] Signal semantics for /sbin/init

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Dave Hansen <haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:

> On Mon, 2007-10-29 at 19:24 -0600, Eric W. Biederman wrote:
>> 
>> When sending a signal to init.  The presence of a signal handler
>> that is neither SIG_IGN nor SIG_DFL allows the signal to be sent to
>> init.  If the signal is not sent it is silently dropped, without
>> becoming pending.  Further if init specifies it's signal handler as
>> SIG_IGN or SIG_DFL all pending signals will be dropped.
>
> Does this mean that container-init processes are specially treated when
> signalled from _outside_ the container for which they are the init?

My proof of concept patch still needs the extra logic from sukas
follow on patch.

The result is that container_init processes will _not_ be treated
specially when signaled from outside the container.  They will
be treated like normal processes.

This becomes straight forward to do because we move all of the
decision logic for dropping signals into the sender.

To maintain backwards compatibility we need only drop signals that
have a signal handler of SIG_DFL, not SIG_IGN (oops).

Eric