On Sat, May 28, 2016 at 9:41 AM, 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.
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". > 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. > 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. > > Zbyszek > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
