[lkml]   [2011]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


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