[lkml]   [2008]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/6][v3] Container-init signal semantics
Sukadev Bhattiprolu <> 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

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.


 \ /
  Last update: 2008-12-22 11:59    [W:0.055 / U:86.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site