musings on session service mgmt

[Havoc Pennington]

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