[ConsoleKit] need better way to start sessions

[Yclept Nemo]

Yikes and apologies, this time I send the mail to the mailing-list...

On Wed, Mar 3, 2010 at 1:18 PM, Stef Bon <stef at bononline.nl> wrote:
> On Tuesday 02 March 2010 17:16:29 Yclept Nemo wrote:
>> As more applications start depending on consolekit, the current method
>> to attach ck sessions is growing inadequate:
>>
>> in ~/.xinitrc
>> "exec ck-launch-session window_manager"
>>
>> So far:
>> polkit-gnome-authentication-agent
>> dbus ?
>> pulseaudio
>>
>> to varying degrees all need to be started after the consolekit session
>> is initialized. Traditionally applications are started in ~/.xinitrc.
>> Now it seems they no longer can be. Alternatives don't appear that
>> feasible:
>>
>> 1) run the necessary programs afterwards in window-manager
>> initialization scripts.
>>   - window-managers were not designed to start programs. Some
>> minimalistic window-managers would require adjustments or redesign or
>> bulky work-arounds to allow this.
>>
>> 2) in ~/.xserverrc run "exec ck-launch-session /usr/bin/X -nolisten tcp"
>>   - doesn't work (tested): X is not a parent process of its clients
>>
>
> Huh?

Good point, I didn't do enough research. Since X is not a parent
process of its clients, I assumed access to consolekit sessions was
determined through process (ppid) parentage (read below, point 3).
Actually access is determined by verifying the XDG_SESSION_COOKIE
variable. However, since environment variables are automatically
exported to children processes, for all intents and purposes, access
to consolekit sessions *is* determined through process parentage.

>
>> 3) in ~/.xinitrc run all the files in ~/.xinitrc.d/*
>>   - bulky redhat-ism (split everything up)
>>   - Since it seems access to consolekit is decided on process
>> parentage (ppid) implementation won't work: processes from
>> ~/.xinitrc.d/* would be owned by init
>> $ cat ~/.xinitrc
>> files=(~/.xinitrc.d/*)
>> for i in "${files[@]:0:${#files[@]}-1}"; do
>>     "${i}"
>> done
>> exec "${files[@]: -1}"
>> echo "finished"
>>
>> 4) in ~/.xinitrc call a manual chain of "xinitrc_afterwards scripts"
>> For example:
>> exec ck-launch-session (one_process &; two_process &; exec window_manager)
>>   - bulky workaround
>>   - illegible syntax
>>   - variation on (3)
>>
>
> Have you thought about upstart? CK is not a tool to start session, only to
> report about changes in them. There is this ck-lauch-session tool, but it is
> old, and used in older releases of CK. Correct me if I'm wrong, it was
> intended to report a session is started, but this is now done by PAM
> integration and the CK daemon. Maybe it's of any use when the app is not using
> PAM.

To be accurate "ck-launch-session" passes a request to initiate a new
session to the ConsoleKit daemon along with some crucial information
such as:
x11-display
x11-display-device
unix-user
And probably most of the parameters "ck-list-session" returns. If
"ck-launch-session" is successful it then sets the XDG_SESSION_COOKIE
environment variable which is inherited by all children processes.

It doesn't matter if the ConsoleKit daemon
("/usr/sbin/console-kit-daemon") is not running because the ConsoleKit
service file at
"/usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service"
ensures that any call to the org.freedesktop.ConsoleKit D-Bus
interface will initiate the ConsoleKit daemon under the root user.

Since the login binary "/bin/login" is already integrated with PAM -
and assuming that the pam_ck_connector is enabled in
"/etc/pam.d/login" - logging in via agetty/tty or similar will
automatically initiate a new ConsoleKit session.

As you point out, however, apps lacking PAM integration such as
"xinit" or "startx" need to manually start a ConsoleKit session. In
this respect "ck-launch-session" is definitely required and certainly
not deprecated. Unfortunately this tool starts a new user-shell
(bash,zsh, whatever) instead of exporting the XDG_SESSION_COOKIE to
the current shell.

>
> With upstart you can trigger an event like "session-started" (and add the
> right parameters). You can now start everything you want to when this event
> occurs, you only need to program the various upstart event files.

I'm not looking to reinvint the wheel; I have no desire to introduce a
completely new process and boot-process manager. I'm simply looking
for a convenient method to start new ConsoleKit sessions that will
integrate well with existing boot methods.

Even though new sessions probably can be created via D-Bus calls,
"ck-launch-session" is much more convenient: it takes care of passing
the correct parameters and setting the correct environment variables
and who knows how much else.

So a new binary such as "ck-attach-session" - simple variation on the
existing tool - would be the preferred and simplest solution.

>
>
> Stef Bon
>

thanks,

#######################################

On Wed, Mar 3, 2010 at 4:20 PM, Ray Strode <halfline at gmail.com> wrote:
> Hi,
>
>
>> in ~/.xinitrc
>> "exec ck-launch-session window_manager"
>>
>> So far:
>> polkit-gnome-authentication-agent
>> dbus ?
>> pulseaudio
>>
>> to varying degrees all need to be started after the consolekit session
>> is initialized. Traditionally applications are started in ~/.xinitrc.
>
> If you use .Xclients or .xsession you shouldn't need to do anything special
> (on Fedora at least), you'll get a ck session "for free".  You'll also
> get a dbus session.
>
> pulseaudio should be activated automatically when used, and the polkit
> authentication agent
> should get autostarted by your session manager.

I wonder how Fedora does this. I do have one CK session from login/pam
but no X11 session.
Unfortunately my window manager does not have a session manager.
Even though "/usr/bin/pulseaudio" is started automatically I prefer to
use "/usr/bin/start-pulseaudio-x11", a little script that initializes
runtime X11 parameters.

>
>> So a suggestion:
>> A consolekit tool that will attach a ck session to the current
>> process. "ck-attach-session" would not return until the session has
>> been initialized. It can be placed in the beginning of ~/.xinitrc, and
>> it wouldn't require major changes to the current ~/.xinitrc workflow.
> It might make sense to make ck-launch-session have an "eval" mode
> like dbus-launch, ssh-agent, etc have.
>
> also having a ck-join-session that moves a shell to an already running
> session would be useful.
>
> Might be worth filing an RFE in bugzilla.
>
> --Ray
>

Agreed, some extra tools will be useful. I'll wait a while to see if
there are any more comments.