>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.
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.