On 28 May 2016 14:42, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl>
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"
> >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
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
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
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.