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.
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 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'
"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.
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.
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
=== 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:
in $HOME/.xsession to have startx run the complete Xfce desktop environment.
So I went ahead and tried putting this into my
#!/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.
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:
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.