On 28 May 2016 14:42, "Zbigniew Jędrzejewski-Szmek" <zbys...@in.waw.pl> wrote: > > On Fri, May 27, 2016 at 07:03:23PM -0400, Paul Wouters wrote: > > On Fri, 27 May 2016, Chris Murphy wrote: > > > > >It seems to me systemd should be able to know the difference between > > >a program that's zombie or unresponsive but isn't doing anything or is > > >unresponsive but is doing something; and if not then some way for > > >programs to say "hey wait just a minute, I need to clean things up" or > > >whatever, rather than just abruptly killing them. > > > > That invention is otherwise known as "unix signals". > > > > systemd should not be the process police. If there is a systematic > > problem of badly written code leaving orphaned code running when > > a user logs out, then that broken code should be fixed instead of > > adding another layer of process management. systemd is not capable > > of interpreting the user's intent. > > systemd *is* process police. That's the job of init. > > The sentiment of fixing processes which cause a problem is nice, > but it's a game of whack-a-mole that you cannot win. For example in > https://bugs.freedesktop.org/show_bug.cgi?id=94508#c10 > it's hp-systray and some ibus related processes. Another time it'll be > some other random process that is hung or misimplemented or confused. > Once you have at least one process staying around, the login session > remains in "closing" state. As long as the session stays around, the > user's user@.service stays around, and this means many more processes > staying around. It's a problem on a single-user system because when > the user logs in again the state is not clean and processes from the > old session are still holding files and resources. On a multi-user > system it's also a problem, for the same reasons, and also because by > default you don't want users consuming resources after they have > logged out. > > Before cgroups came around we really didn't have a mechanism to make > accounting of processes automatic, so the only possibility was to hope > that processes behave nicely, and let the administrator kill > misbehaved processes by hand. This applied to both system services and > user sessions. With systemd as pid1 we moved to a model where system > services are managed and anything they leave behind is killed. This > is a corresponding change to user sessions and user services. > The same as with system services, we need to figure out what the > exceptions are and which user services need special handling, but the > default should be to clean up everything. >
There is some sense there but I do concur with the others that this should be listed as a system wide (not even self contained) change for F25 due to the impact and the critical path component. For now might I suggest you do a fresh rawhide build with logind.conf setting the old behaviour, and then issue a F25 change for FESCO to discuss. Once FESCO have ruled on this then we can follow their direction in assuming the new behaviour, and document how to background a process in the F25 changes/release notes.
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
