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: ck-launch-session window-manager 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 sources xinitrc.d/??* (for example 99consolekit, 75dbus-launch) STARTUP= STARTUP="dbus-launch --sh-syntax --exit-with-session $STARTUP" STARTUP="ck-launch-session $STARTUP" exec $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)" fi 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* DBUS_SESSION_BUS_ADDRESS='...'; export DBUS_SESSION_BUS_ADDRESS; DBUS_SESSION_BUS_PID=...; 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.