Bug 27089

Summary:	[RFE] Extra command-line tools
Product:	ConsoleKit	Reporter:	orbisvicis
Component:	Daemon	Assignee:	william.jon.mccann
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	medium	CC:	orbisvicis
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description orbisvicis 2010-03-15 09:37:54 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.

Comment 1 orbisvicis 2011-02-07 10:04:11 UTC

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.