Hi,
David Zeuthen wrote:
2. I think we've all experienced this one or more times; you log out
of your session and log back in. Wow, now things are weird or maybe
doesn't even work. The reason for this is that processes from your
old session keeps hanging around. In fact, I was bitten by this just
before the holidays; I simply couldn't login. Why? An old gconfd
process was lingering and that blocked login. The solution? Log in
as root on VT1 and do the usual 'killall -9 -u davidz' dance.
This may be obvious, but the "correct" solution is supposed to be that
apps should connect to either the X server or the session message bus
and they should exit when the X server or message bus does. (Both Xlib
and libdbus exit on disconnect by default for this reason.)
Other solutions are pretty much hacks, I mean, they may be worthwhile
and pragmatic hacks, but, nonetheless. Apps should be exiting with the
session already or they are buggy.
One alternate approach might be to write a little babysitter/proxy app
(just like the way dbus-launch ties the session bus to the X server).
The babysitter app would connect to the session bus, then exec its args
as a child process, and kill the child process when it lost the
connection. Of course, this involves modifying any code that launches a
session service so it launches it with the babysitter, so perhaps not ideal.
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it
does this is because of the way that ConsoleKit works. It basically will
just kill all the processes where the uid and the environment variable
XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few
seconds, it moves on to SIGKILL (e.g. -9).
I would think this should only be done after the session bus is gone and
apps have had a chance to cleanly exit, and maybe some kind of warning
should be logged like "crappy app xyz had to be killed"
There is a race, where a correct app that was on its way to exiting on
its own gets killed because it was too slow... but in practice I doubt
that would happen too much.
Havoc
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
