[Pkg-xfce-devel] X and consolekit

Yves-Alexis Perez corsac at debian.org
Tue Apr 28 18:39:41 UTC 2009


I'm forwarding your mail to the pkg-xfce mailing list. Please reply
there too, so the team is aware of the issues.

I'm taking some time to think about it and maybe do some tests. Then
I'll write a more complete reply.

pkg-xfce:
On mar, 2009-04-28 at 11:47 -0600, Scott Barker wrote:
> I didn't want to clutter the bug report, so I thought I would email you 
> directly with this info. If you know all this already, please forgive me 
> for wasting your time. If you prefer this in the bug report, let me know 
> and I'll forward a copy there as well.
> 
> As far as I can tell in my testing, consolekit creates a session for the 
> current tty only. If you have libpam-ck-connector installed, you get a 
> console session created for the tty you login on (for example, tty1).
> 
> However, the X session runs on a different tty (for example, tty7), and 
> does not inherit the session from the original login tty (tty1). Thus, 
> during the X startup, a new console session must be created.
> 
> 'startxfce4' does not do this at all. 'startx' tries to do this (via 
> /etc/X11/Xsession.d/90consolekit), but if you have libpam-ck-connector 
> installed, libpam-ck-connector sets XDG_SESSION_COOKIE, which prevents 
> 'startx' from creating the new console session with ck-launch-session 
> (due to the logic in /etc/X11/Xsession.d/90consolekit).
> 
> Further, since ck-launch-session creates a session for the current tty, 
> it cannot be run until after the tty for the X session (tty7) is created 
> by xinit. So, for example, starting X with 'ck-launch-session 
> startxfce4' or 'ck-launch-session startx' will not work, because the new 
> session will be created on tty1 (since xinit hasn't created tty7 yet).
> 
> So, ck-launch-session must be invoked by xinit after xinit creates the 
> tty for the X session (tty7). The /etc/X11/Xsession.d/90consolekit 
> script handles this (when not blocked by libpam-ck-connector) by 
> crafting the $STARTUP shell variable with a client command line for 
> xinit to invoke that includes ck-launch-session at the appropriate point 
> in the command string (after ssh-agent and before dbus-launch).
> 
> Thus, xinit will create tty7, and run ssh-agent as the client, with 
> arguments that cause ssh-agent to run ck-launch-session (which creates 
> the console session on tty7 that was just created by xinit), with 
> arguments that cause ck-launch-session to run dbus-launch, with 
> arguments that cause dbus-launch to start the actual session manager. 
> So, dbus and the session manager will both inherit the new console 
> session correctly. Of course, this only works when libpam-ck-connector 
> is not installed (as mentioned above).
> 
> If you purge libpam-ck-connector and set the x-session-manager 
> alternative to /usr/bin/xfce4-session, then when you run 'startx', xfce4 
> will start appropriately, with all of the correct authorizations from 
> consolekit/policykit.
> 
> However, I noticed that there are some oddities with starting xfce4 this 
> way (for myself, anyway), and I assume it is because all the environment 
> variables set by the startxfce4 and /etc/xdg/xfce4/xinitrc scripts are 
> not configured when starting xfce4-session directly in this manner.
> 
> So the final portion of my fix avoids calling xfce4-session directly, 
> and runs /usr/bin/startxfce4 instead. To do this, I created a .xsession 
> file in my home directory to over-ride the x-session-manager default in 
> the /etc/X11/Xsession.d/* scripts. In the .xsession file, I put 'exec 
> startxfce4'.
> 
> Now, I can start my X session with 'startx', and xfce4 will get started 
> in a similar manner as running 'startxfce4' directly, but with a correct 
> console session set up.
> 
> Does that all make sense? I hope so, I don't want to cause more confusion.
> 
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20090428/6cb6bcd6/attachment.pgp>


More information about the Pkg-xfce-devel mailing list