Bugzilla – Bug 27089
[RFE] Extra command-line tools
Last modified: 2011-02-07 10:04:11 UTC
It might be worth enhancing the consolekit toolset. Two suggestions:
ck-attach-session: 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.
Use case: "ck-attach-session" can be placed in the beginning of ~/.xinitrc, and wouldn't require major changes to the current ~/.xinitrc workflow.
Implementation: it was suggested to have either "ck-launch-session" or "ck-attach-session" work in "eval" mode similar to dbus-launch, ssh-agent, etc, if possible.
ck-join-session: a consolekit tool that moves a shell to an already running session
The thread discussing these tools is archived at http://lists.freedesktop.org/archives/consolekit/2010-March/thread.html under "[ConsoleKit] need better way to start sessions". I think it's worth reading.
The current way to start a desktop environment with consolekit is to run:
But all the applications that need to inherit $XDG_SESSION_COOKIE need to be started after ck-launch-session and before the window manager (keep in mind that not all window manager provide methods to launch start-up applications).
This leads to the hackneyed approach found in gentoo/ubuntu/debian:
xinitrc.d/??* (for example 99consolekit, 75dbus-launch)
STARTUP="dbus-launch --sh-syntax --exit-with-session $STARTUP"
However this approach only handles modifying the window-manager launch command, and not starting custom applications. An alternative is
xinitrc.d/00-start.sh: "ck-launch-session xinitrc.d/10-dbus.sh"
xinitrc.d/10-dbus.sh: "dbus-launch --sh-syntax --exit-with-session xinitrc.d/20-apps.sh"
xinitrc.d/20-apps.sh: "app#1 & app#2 & app#3..."
Which is only another difficult and convoluted approach to a badly-thought-out architecture.
DBus has the correct approach with dbus-launch:
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ];then
eval "$(dbus-launch --sh-syntax --exit-with-session)"
01. This allows conditional guarding to check that a previous dbus session is no longer available.
02. The dbus-launch program makes the necessary environment variables available to the *current* shell*
03. The dbus-launch command starts a second? dbus-launch wrapper and the dbus-daemon command which automatically exits with the caller.
This is why the method of registering a consolekit session needs to be rethought, or a dbus-style wrapper written.