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

Re: musings on session service mgmt



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


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