On 29 May 2016 5:02 a.m., "Nico Kadel-Garcia" <nka...@gmail.com> wrote: > > 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". >
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.
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
