On 6/2/2016 7:04 AM, Lennart Poettering wrote:
In all of these cases you really want to make sure that whatever the user did ends – really ends – by the time he logs out.
I apologize if this has already been brought up, but I didn't see this particular point raised in the replies I've read and I wanted to be sure it is mentioned.
The potential problem I see with changing the default behavior of systemd is that it is non-intuitive and could be potentially harmful if the user is not aware of it. Consider the following example. I routinely use screen when I connect to the systems I manage remotely specifically when I try to apply updates. I do this because if my VPN connection or my Internet connection is interrupted, the update process will not die with my login session. Incidentally, I learned to use screen when applying updates the hard way many years ago when a killed update wreaked havoc with a system of mine and I found screen to be an excellent solution.
Currently screen is a utility whose purpose is, in part, to allow a user to disconnect from a running process in a safe way that will allow it to keep running and be resumed in the future from another session entirely. Now that will only be valid if the user knows whether or not systemd is configured on the system in question to not automatically reap these kinds of processes. This would have the effect of transforming what is clear and precise documentation of a well known and widely used utility into something that relies on another set of system configuration settings that are arguably not as intuitive.
For the record, I am not trying to say I am opposed to increasing system security and progress in general in the slightest - both are laudable goals. What I am trying to say is that there is a lot of merit in making sure things are not made unnecessarily more complex and difficult to discern unnecessarily. Whatever needs to be done to increase security needs to be done while embracing the notion of not pulling the rug out from under legitimate uses of programs whose indiscriminate and unexpected reaping could cause disastrous results.
Tom -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
