lkml.org 
[lkml]   [2008]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 0/6][v3] Container-init signal semantics
Date
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:

> This patchset implements the design/simplified semantics suggested by
> Oleg Nesterov. The simplified semantics for container-init are:
>
> - container-init must never be terminated by a signal from a
> descendant process.
>
> - container-init must never be immune to SIGKILL from an ancestor
> namespace (so a process in parent namespace must always be able
> to terminate a descendant container).
>
> - container-init may be immune to unhandled fatal signals (like
> SIGUSR1) even if they are from ancestor namespace (SIGKILL is
> the only reliable signal from ancestor namespace).

It sounds you are still struggling to get something that works and gets
done what needs to be done. So let me suggest a simplified semantic that
should be easier to implement and test, and solves the biggest problem
that we must solve in the kernel.

- container-init ignores SIGKILL and SIGSTOP.

- container-init is responsible for setting the rest of the signals
to SIG_IGN.

If that isn't enough for all of the init's we can go back and
solve more in kernel land. That simplified semantic is certainly
enough for sysvinit.

> Limitations/side-effects of current design
>
> - Container-init is immune to suicide - kill(getpid(), SIGKILL) is
> ignored. Use exit() :-)

That sounds like correct behavior.

Eric


\
 
 \ /
  Last update: 2008-12-22 11:59    [from the cache]
©2003-2011 Jasper Spaans