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    [W:0.026 / U:0.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site