3 ms·
I'm curious: Why is the init daemon what a local process should communicate with? A daemon that managaes other daemons doesn't need to be PID 1, even to reap
by codemac 12y ago
I'm curious:
Why is the init daemon what a local process should communicate with?
A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies.
Secondly, daemons shouldn't care what process is managing them, a principled approach to communication between the daemon manager and a daemon would probably include handing off sockets/ports/fds, but probably not much else.
- thwarted 12y ago>A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. And get this, prctl(PR_SET_CHILD_SUBREAPER) has existed since May 2012, the original patch was created and submitted by Poettering, and yet we're still told that service management needs to run as pid1 in order to see all double-forked detached daemonized processes.
- rodgerd 12y ago> Why is the init daemon what a local process should communicate with? Because there could, and I know this is a crazy thought, be some benefit in having more meaningful information flow between the master of processes and the processes it manages?