On Sat, May 28, 2016 at 9:41 AM, Zbigniew Jędrzejewski-Szmek
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
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
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.
> 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.
> devel mailing list