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    [from the cache]
©2003-2011 Jasper Spaans