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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
