= phenomenon = It is not acceptable for Fedora to change behaviors that impact system administrators using Fedora in a Server/Cloud environment without a clear guideline and clear transition plan.
= background analysis = Processes executed by users logging into a shared system may have certain processes left running in background, GNU screen being one example.
It is expected when the user logs out those processes remain running, especially when it is - explicitly - requested by using such programs.
= implementation recommendation =
I would like FESCo to review this change and provide a better method for this change, some possible solutions are:
1) A grace period, before this is switched on. [[br]] 2) A whitelist of programs that expect the previous behavior to remain [[br]] 3) Patches for affected programs (and provided to upstream)
Users who rely on Fedora in a Server capacity will not be expecting this change. I would request we have a whitelist mechanism initially to transition to the new default.
This should also be flagged as a System wide change.
As a member of the Fedora Server WG, I wholeheartedly support spstarr's argument. This change is too drastic to make without some mechanism to retain previous standard behavior in place.
Changing systemd like this in order to work around a bug in a single desktop environment has a huge and negative affect on using Fedora as a server distro. I have also heard complaints from users of other distros where this affects them, even in their desktop use cases. The proper fix for the original issue should come from the Gnome and dbus developers and should affect those components only.
Personally, this affects my own desktop as well as server use cases, as I have applications that I run that I would like to have persistent even if I log out. If this particular feature is to remain in systemd, it should be disabled by default for all but the Gnome spin, even though the proper solution would be to fix Gnome3/dbus.
I'm not prepared to visit a judgement on the specific value of this feature in the long-term. I understand arguments both for and against activating such a feature.
However, I am willing to say flat-out that the systemd upstream did not approach this change in the correct manner. Any change that has such far-reaching impact should never be dropped into a distribution unannounced. At best, this should come in as a Change Proposal and then be discussed by FESCo first. (And if the rebase including it was necessary for other reasons, then the change should be patched out until approved for inclusion).
I offer the following formal proposal for FESCo to consider:
Proposal: systemd must revert the change in default functionality for !KillUserProcess immediately. This change '''may not''' occur in Fedora before Fedora 25 and may only do so in Fedora 25 or later with approval through the Change Process.
Approval through the Change Process will almost certainly require coordination with the packages most affected by this change (such as screen and tmux) and FESCo will reserve the right to keep this option disabled until such time as a critical mass of affected packages have been updated to work with it.
Replying to [comment:5 sgallagh]:
I'm not prepared to visit a judgement on the specific value of this feature in the long-term. I understand arguments both for and against activating such a feature. However, I am willing to say flat-out that the systemd upstream did not approach this change in the correct manner. Any change that has such far-reaching impact should never be dropped into a distribution unannounced. At best, this should come in as a Change Proposal and then be discussed by FESCo first. (And if the rebase including it was necessary for other reasons, then the change should be patched out until approved for inclusion). I offer the following formal proposal for FESCo to consider: Proposal: systemd must revert the change in default functionality for !KillUserProcess immediately. This change '''may not''' occur in Fedora before Fedora 25 and may only do so in Fedora 25 or later with approval through the Change Process. Approval through the Change Process will almost certainly require coordination with the packages most affected by this change (such as screen and tmux) and FESCo will reserve the right to keep this option disabled until such time as a critical mass of affected packages have been updated to work with it.
Just to be clear, the Proposal here is to have the !KillUserProcesses value to be set to "no" by default in /etc/systemd/logind.conf until there is a proper migration plan in place for impacted applications?
Replying to [comment:8 maxamillion]:
The Proposal is that the !KillUserProcesses value is set to "no" by default for now. Whether or not this ''ever'' changes should be determined through the normal Change process. There are three possible outcomes of the Change process as I see it: FESCo decides that the !KillUserProcesses doesn't add value and asserts that it remain "no" for the foreseeable future. FESCo identifies and mandates a set of conditions (such as a migration plan) that must be met before the default can change. * FESCo just goes ahead and approves the Change as-is.
Any of those are legitimate approaches, but should be debated and agreed-upon ''before'' stuff lands in Fedora.
Replying to [comment:9 sgallagh]:
Replying to [comment:8 maxamillion]: Just to be clear, the Proposal here is to have the !KillUserProcesses value to be set to "no" by default in /etc/systemd/logind.conf until there is a proper migration plan in place for impacted applications? The Proposal is that the !KillUserProcesses value is set to "no" by default for now. Whether or not this ''ever'' changes should be determined through the normal Change process. There are three possible outcomes of the Change process as I see it: FESCo decides that the !KillUserProcesses doesn't add value and asserts that it remain "no" for the foreseeable future. FESCo identifies and mandates a set of conditions (such as a migration plan) that must be met before the default can change. * FESCo just goes ahead and approves the Change as-is. Any of those are legitimate approaches, but should be debated and agreed-upon ''before'' stuff lands in Fedora.
+1 to this proposal
Putting this on the agenda for the FESCo meeting tomorrow, Friday at 16:00UTC in #fedora-meeting
It would help if you put at least one systemd maintainer in the CC. If sgallagh hadn't pointed it out on IRC, I wouldn't have been aware of this ticket at all.
I'm fine with filing a F25 Change page for this.
Adding support to programs like tmux and screen is a good idea. In fact I opened an RFE in the tmux bugtracker, which didn't get too far. Screen might be easier, especially considering that it already has PAM support. I haven't had to time to look into the details though.
We discussed it in today's meeting and decided that we'd back out the KillUserProcess change in rawhide for now. zbyszek is going to come up with a Change proposal for this and what other modules need fixing and then we'll evaluate if it makes sense to change the default and how to approach this.
Login to comment on this ticket.