Oh fun

So after my latest X.org upgrade I forgot to recompile the xf86-input-evdev module as well. So of course when I ran startx again, my shiny KDE desktop came straight up… and I couldn’t move the mouse or use the keyboard. Drat.

Now I’ve been much more careful to cleanly shutdown KDE when possible ever since I started losing rc files with my previous filesystem. And besides which, I couldn’t use Ctrl-Alt-Backspace even if I wanted. So what I did instead was login with my laptop to try and shutdown KDE.

Of course, there’s still the tricky issue of how to cleanly shutdown your running session from a completely different shell. Luckily ksmserver (the process responsible for performing the shutdown) has a DBus interface:

kde-svn@midna ~ $ qdbus org.kde.ksmserver /KSMServer
method bool org.kde.KSMServerInterface.canShutdown()
method QString org.kde.KSMServerInterface.currentSession()
method void org.kde.KSMServerInterface.logout(int, int, int)
method void org.kde.KSMServerInterface.resumeStartup(QString)

Of course, that’s what I get when I run if from my current KDE session. I was worried that in my ssh shell there would be problems with accessing the D-Bus session. So imagine my surprise when I was wrong, the command worked just fine even with no environment variable set. Huh.

Although it saved me from what I was going to do (look through /proc/pid/environ for a process that I knew was in the DBus session), it was still unexpected to me. Turns out that DBus will, if the environment variable is unset, try to “autolaunch” the session bus. This entails looking in the X session and in ~/.dbus/session-bus/ to look for the information on the DBus session, and if not able to locate the session, to simply launch another DBus session. In my case the information was available in ~/.dbus/session-bus/.

So I’m impressed, I was expecting it to be a giant pain in the ass and it was actually ridiculously simple.

Btw, the conclusion to the tale was: qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout 0 0 0. The three parameters were annoying for me to lookup so here it is:

The real signature: KSMServerInterface::logout( KWorkSpace::ShutdownConfirm, KWorkSpace::ShutdownType, KWorkSpace::ShutdownMode ). The parameters are essentially the same as in KWorkSpace::canShutdown() (link edited to work 2012-05-06), and the values are defined on that API page as well. One thing to note is that the final 0 (shutdown mode) is actually useless since we’re not requesting that a shutdown happen, only a logout. If we were requesting a shutdown, the shutdown mode is what selects whether to force a shutdown/reboot even if other people were also logged in, for instance.

Kind of as an aside, I’ve taken the liberty of updating my GPG keys due to the relative insecurity and low strength of the 1024-bit DSA key I had before. It should have a fingerprint of 5406 ECE8 3665 DA9D 201D 3572 0BAF 0C9C 7B6A E9F2, and is available here. Maybe someday I’ll even be able to attend a keysigning event to get it signed by someone else. :-/