[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: musings on session service mgmt

On Fri, 2008-01-04 at 11:29 -0500, David Zeuthen wrote:
> Nils, it's very evident you are in the annoying "oh, but it's worked
> this way forever so we can't change it" camp. You need to accept that
> some of us are not and your camp is sometimes perceived as hindering
> progress.

David, you should have listened in on some of the conversations I had
with colleagues in the office, then you would have to admit that putting
me in the "change is baaad" crowd is a bit far-fetched.

If I wanted to talk in terms of "camps" or "crowds" (which I don't,
because this kind of simplification just causes hostilities), then I'd
put myself in the "let's look at this from all angles" or "don't break
things without good cause" corners. Granted, this in itself is a sure
recipe to annoy more people and it would help if I not just criticized
stuff but also e.g. talked about where I experience new things as
positive. Apologies for that.

>  The indisputable fact is that X11 session service management
> is just *broken* as I outlined in my original mail. The fact that some
> people take advantage of this brokenness via screen, nohup etc. doesn't
> mean we shouldn't fix the fundamental problem. Doesn't mean either we
> shouldn't fix the few oddball cases such as screen and nohup to opt out
> of getting reaped.

If I'm not off track, at least screen predates X session management by a
few years. So if anything, X session management was (for want of a
better word) designed to not make established ways how to make a process
a daemon (and screen, nohup etc. do nothing else) break. It's bad that X
session management is broken, but I don't see a compelling reason yet
why stuff that has got nothing to do with X should accommodate
workarounds for such brokenness.

Or to phrase it in a (hopefully) less annoying way: I think it should be
feasible to have programs which should end with the session be
"bound" (by whatever means) to the session manager in a way where the
session manager kills them off at the end of the session without making
this leak to all child processes. Kind of like POSIX process groups,
where the session manager takes the role of the process group leader.
Hey, if GUI apps wouldn't have the obnoxious habit of disconnecting from
their parent processes (e.g. via the fork()/exit() "workaround" you
mentioned in another post), we even might get by with walking the
process tree from the session manager process downwards.

Talking about the issue at hand, there are already two ways that cause
processes to end if the session ends (libX11 and dbus), it should be
easy enough to fix the remainder properly.

     Nils Philippsen    /    Red Hat    /    nphilipp redhat com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]