lkml.org 
[lkml]   [2011]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: + prctl-add-pr_setget_child_reaper-to-allow-simple-process-supervision .patch added to -mm tree
    O> Why would it? Systemd can serialize its state and properly re-exec
    > itself as many times as needed during its lifetime. Why would the
    > kernel take something away from a process, which it explicitly asked
    > for?

    Because a re-exec is a change of context, in the same was as a re-exec
    closes some file handles kills alarms, adjusts signals etc. Across an
    suid boundary of course it gets even more important.

    Why would the kernel allow a parent process, possibly with a different
    security context, to muck with defined and guaranteed standards compliant
    behaviour it may rely upon.

    > Hmm, I don't see why that would be necessary. It's just one of our
    > parents that aks for our signals.

    I think it is fundamentally the wrong answer. The behaviour in question
    is in every Unix since day one and apps rely upon it.

    Now I can see why you want to know when processes exit and do it without
    tampering with the process, but it seems to me that's simply a question
    of us lacking a way to do this nicely, whether inotify/dnotify/etc
    on /proc, some kind of 'also signal me' property or some kind of process
    event interface.

    Of those a signal based one seems the weakest because programmers and
    signal often don't mix well because it is asychronous and also because it
    wouldn't naturally allow multiple users (eg a process monitoring tool and
    systemd to share)

    For that matter your init process could farm them back out down a named
    pipe or some other such interface and do the monitoring in userspace.

    Alan


    \
     
     \ /
      Last update: 2011-08-17 19:27    [W:0.026 / U:0.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site