On 29 May 2016 5:02 a.m., "Nico Kadel-Garcia" <nkadel(a)gmail.com> wrote:
On Sat, May 28, 2016 at 9:41 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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.
daemon poloce != process policie, especially user processes which have
nothing whatsoever to do with system daemons. If it's gong manage user
personal environments, it should be a separate set of tools called
"userd".
Now whilst a support a reversion of the behaviour in Rawhide right now
whilst a FESCO F25 change ticket goes through let's not be silly... and at
any rate this is technically logind managing this aspect ;)
> 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.
It can be a problem. Enable this kind of aggressive userland
manipulation by *request*, instead of by default, and you're far less
likely to break longstanding procedures such as the ssh-agent
configurations I just mentioned, and the user-activation of other
credentials such as Java keystore.
Well that's what the Change process and Release Notes are about so when the
way to handle something changes (and as mentioned there are ways of
initiating a separate scope for these to be in their own session) admins
and users are able adapt their configurations during a release upgrade.