>"untrusted" So you're going to "trust" i.e. deputize some theoretical daemon that will still have to pass the simple data structures to systemd, which won't a

>"untrusted" So you're going to "trust" i.e. deputize some theoretical daemon that will still have to pass the simple data structures to systemd, which won't actually fix, or fix any future incarnations of, the bug that we're discussing. >What does that suggest about the architecture of systemd? It suggests that it is, at worst, the same as the status quo on Solaris and macOS. In reality, the community is filled with people waving their hands and doomsaying against "complexity", ignoring the fact that their suggested actions don't really solve anything. They seem to be a cargo cult of modularization, if you catch my drift. Along with all of the comments in the thread suggesting languages that can't fork, and languages that can easily lose track of daemons even when the daemon doesn't double fork, we can see that not every suggestion that sounds reasonable is actually reasonable, or better. Additionally, there's probably some lesson about `PR_SET_CHILD_SUBREAPER` and what happens when the subreaper they so desperately want to exist crashes. If systemd were running as PID2, and crashed, children would simply be inherited by PID1, and now we need to communicate everything to the service manager. You can't set subreaper again, after it crashed. So really, what are we arguing about here?