I recently upgraded from Debian squeeze to wheezy. As happens with these upgrades, I was awash in things that no longer worked quite the way I expected them to, and configuration changes to make.

This is the first of a couple pieces on what I did to get things working to my liking. As the title suggest, this is about the the interactions of startx, ConsoleKit, and Xfce 4.8. Or, more accurately, how the interactions between those things broke in my setup when I upgraded, and how I got it working again.

Setup

As noted, I run Debian wheezy. The machine is an aging Thinkpad x61 (amd64). It had been running squeeze for the last couple of years, at least since squeeze was testing, when I installed it through a clean reinstall.

I've been using Xfce for a long time. The move from squeeze to wheezy included a pretty major Xfce upgrade. The improvements between Xfce 4.6 and Xfce 4.8 are noticeably huge, it is faster, and handles some things better than the old version. Thankfully most of my tweaks to the look and feel didn't get too mangled on the upgrade. My profile settings were all in tact.

The only other bit of the setup that is relevant to this, is that I don't use a display manager. Instead I just run startx from the console — which has worked until now..

The Problems

PolicyKit bug

The first issue has to do with Xfce and ConsoleKit, something I've seen called called the the PolicyKit bug. Some time between Xfce versions 4.6 and 4.8, Xfce started referring to a console kit session to find out if it could let you do things like suspend or shut down. There are various other things that check the console kit session, and anything that does check it won't work if console kit isn't part of the session that you're running.

To see your running console kit sessions, run ck-list-sessions. With everything working, it looks something like this:

0 nat@pigtown:~$ ck-list-sessions
Session82:
unix-user = '1000'
realname = 'nat'
seat = 'Seat1'
session-type = ''
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty1'
remote-host-name = ''
is-local = TRUE
on-since = '2012-09-06T20:47:24.206129Z'
login-session-id = '57'
idle-since-hint = '2012-09-06T20:48:06.003241Z'
Session83:
unix-user = '1000'
realname = 'nat'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = '/dev/tty1'
remote-host-name = ''
is-local = TRUE
on-since = '2012-09-06T20:47:35.435969Z'
login-session-id = '57'

Notice the "active = TRUE" for Sesson83 (on tty7) that is the active X session. When you have issues with your ConsoleKit, the same command will have "active = FALSE" set.

The problem I was hitting, in short, was that the scripts being run when I ran startx was failing to start Xfce with an active ConsoleKit session. So that was the first issue to solve.

startx & exit

Problem two also has to do with startx, but less what the script was running, than how it was being invoked.

In squeeze, I would launch Xfce (4.6), with a startx & exit. Without the & exit someone could not hit Ctrl-C in tty1 to close the X session and be dropped into a working shell. This would be very bad. Obviously I need to make sure that doesn't happen.

By the time I got the PolicyKit bug cleared up, and was using startx again, it turned out that console kit wouldn't remain active if I left the & exit on my startx command. X and Xfce would still start, just with no ConsoleKit privileges. However, if I remained logged in by leaving out the exit, everything worked as expected. But again, that is not acceptable, because it leaves access to shell.

The solutions

PolicyKit bug

So the first thing I needed to do, was figure out how to get Xfce to load a ck session properly. A little bit of searching revealed that I was not alone. It seems this was a problem for many people in Debian, and was report as a bug in both Debian and Ubuntu.

There were several suggestions on how to get it working, but the best help comes straight from /usr/share/doc/xfce4/README.Debian.

=== Console startup

Users that prefer to start X from the console can use startx or startxfce4.

The former is preferred in a Debian system as it will run all standard X session startup files (ConsoleKit, gpg-agent, ssh-agent etc.). You should not use any .xinitrc or pass any argument to startx (as it'll prevent running the Xsession scripts. Put:

exec startxfce4

in $HOME/.xsession to have startx run the complete Xfce desktop environment.

So I went ahead and tried putting this into my ~/.xsession:

#!/bin/sh
exec startxfce4

It launched, but ConsoleKit was in fact not active. After asking around and digging, I found that the right option to use is:

#!/bin/sh
exec startxfce4 --with-ck-launch

That's it. It works after that. On to problem two.

startx & exit

I liked my old setup of using startx & exit because it left nothing but a login prompt on the tty I used to launch my X session. However if I want the ConsoleKit session to remain active, I have to leave it open. So no matter what, someone can walk up to my machine, and if it is turned on, kill my X session by hitting Ctrl-C on the connected tty. That is annoying, but it is okay, so long as they are not able to get a functional shell — which they're not, i've tried.

Figuring that I'm not the only one who does this, I asked around, and with the help of vagrantc came up with:

exec startx

This will drop the person at a login prompt after killing the X session. Very simple fix.

I updated my bash aliases, so that I can still just run startx, and all is well. Hopefully this can help anyone with a similar problem.