(16-06-2017, 05:00 AM)z3bra Wrote: is a bit irrelevant, because it COULD die. If it does, you'll have more problems than sshd not running though, but it could. If you service manager is badly written, and thus die, then moving all this logic to PID 1 won't fix the crashes. It will only weaken PID 1.

Indeed I agree.

(16-06-2017, 05:00 AM)z3bra Wrote: IMO, there is no valid technical reason to keep service management in PID 1. Not even for orphaned processes, as you will adopt them without any context (it could as well be a simple user process, you can treat all of them as daemons).

After further reading (the links in my previous comment), I have to agree that there were a lot of solutions and aspects I hadn't thought of before.
Especially the fact that the parent of orphaned processes doesn't have to be PID1 and is implementation specific and that reaping zombies isn't a requirement of the init anymore. Init could be, as far as the service manager is concerned, only responsible to respawn it in case of failure.

(16-06-2017, 05:00 AM)z3bra Wrote: To get back to the topic, this is one of the first flaws systemd has regarding service management. The internal logic seems to be okay though, but it is not managed at the good level.

Then, according to you, it's a matter of separation of tasks and delegation through child-processes?