On Fri, 2008-01-04 at 12:12 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 12:04 -0500, Colin Walters wrote:
> Sending SIGHUP to all processes manually is fine; in theory actually the
> kernel will do this for you when the process session group leader exits.
> Now, whether something is correctly set as the process group leader in
> the twisted desktop login stack is an open question. A regression here
> would mostly be masked by the fact that *almost* everything run from the
> desktop does connect to X11.
Lots of programs (including GNOME ones) daemonizes e.g. creates their
own process group etc. etc. so clearly we can't rely on this.
There's no reason for programs to daemonize for the desktop session. If
they are, it's a bug. Most likely it's just a case of someone thinking
their program is l33t because it's a "daemon".
That's why we need to iterate over the process list and send
processes matching the uid and XDG_SESSION_COOKIE (or other attribute
but XDG_SESSION_COOKIE is what we have right now). It's not really
It's also working around bugs in other apps; and I don't think the list
of buggy apps is very large. GConf and bonobo are the two main
You are being vague here; I think you just use that term because
said something vague about a babysitter execing stuff. The way I read
this (it's vague so I'm guessing) sounds like it needs source code
modification and if it isn't clear I don't think that's an option.
It doesn't require modifying apps. The idea is just to have a binary
which monitors X11/DBus, and can fork()/exec() a child binary to
monitor. If X11 goes away, it kills the child. Thus the only thing
that needs to be modified is that the session startup script is changed
dbus-scope-to-session some-random-daemon --args
> But I think (generally speaking) most
> projects nowadays *should* gain a dbus dep, and if we can explain
> clearly to them why it it useful, they would accept it.
I think that is what they call wishful thinking. Seriously.
Let's be more concrete here - what other apps are buggy?