On 28 May 2016 14:42, "Zbigniew Jędrzejewski-Szmek" <zbyszek@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
