Been using systemd for a very long time now and have had no issues. Had a very pleasant time setting up services to start on boot and such.
And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence.
The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
In this case, the only reason that it didn't break more widely is because the adults in the room overrode the default KillUserProcesses=yes at the distribution level.
This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best.
KillUserProcesses=yes is quite a reasonable default for security though, as lingering processes after logout can be an issue on multi-user systems. For example it can be used as protection against fork bombs. I actually have no idea how Linux persisted for so long without something like that, it seems the long-standing standard here was not great. Rememeber that a lot of what a service manager has to do is decide what policies to set based on what security is provided by the kernel, so in some cases all they can do is provide an option and try to set that to the most secure default.
I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html)
Multi-user systems are exactly the use case that makes KillUserProcesses=yes unsuitable as a default. Control groups are good for stability, because as you say, you can manage resource quotes, or kill an entire forkbomb. However, KillUserProcesses goes a step further, and also kills processes whenever there is a network failure. KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user.
Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard.
The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback.
With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.
>KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user.
I can't agree, IMO processes left over after a network connection terminating could be considered a security hole. That's up to the sysadmin how to set it up. I certainly don't suggest getting into the habit of launching long running tasks in an ssh session, a remote sysadmin could already very easily end your processes if they find you AFK launching things on a sensitive machine. Systemd just gives some standard tools to do that.
>Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. [...] The short-term drawback is that programs that correctly request to be long-lived are killed.
This is incorrect, traditionally SIGHUP only means that the controlling terminal was disconnected. What you are describing is only correct for a single login shell with no sub-reapers, on a modern setup there are other things besides logging out that will send SIGHUP, such as for example if you run your program in an xterm and then close the window, or if you are operating within a sub-shell, etc. SIGHUP provides no way to differentiate those conditions, plus some programs will overload SIGHUP to be a "reload config" command, etc. SIGHUP is just not a reliable way to do it, I would not describe that as correctly requesting to be long-lived. SIGKILL is unfortunately the only method the kernel provides to do a reliable cleanup.
>The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
AFAIK there is no portable or simple way to do this, please enlighten me if I am missing something. Using daemon(3) and SIGHUP is not adequate here for reasons described above. Of course other init systems are free to create their own simplified implementation of systemd scopes, while skipping the Linux specific directives if they want. So it's not clear what your actual complaint is and what you mean the drawbacks are. Do they need help doing this? If so I would be happy to advise.
>in both cases, programs can persist, so there isn't a security benefit.
This is also incorrect, in the case of systemd scopes, you can further restrict the ability to create them with polkit or SELinux or similar. So you could make it so only tmux is allowed to start one for example. That would be one of the big benefits of having a real API for this versus just sending a signal and hoping the program is well behaved.
>The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks.
I don't think that is warranted, systemd developers can decide for themselves the trade offs of their program. The vitriol is not needed and is in fact likely to weaken the argument. In any case there are several other inits to choose from with their own set of strengths and drawbacks, I suggest focusing on what choices you have rather than agonizing over the small decisions of just one of them.
And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence.
The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.