Integration of dbus and KDE: starting and stopping the session part of dbus with KDM.

Contents

0. Introduction
1. Adjusting the configuration of KDM
2. Starting the sessiondaemon of dbus and make environmentvariables available.
2.1 About the startupfiles of Bash.
2.2 Starting the sessionbus part of dbus
2.3 Stopping the sessionbus part of dbus
2.4 One user is more than one time logged in

0. Introduction

Since some time now a lot of applications make use of D-BUS. This is the case with
KDE 3.5, the current stable release of KDE. With the upcomming KDE 4, D-BUS is getting more important, replacing DCOP.

In this howto I want to describe a way to start and stop the user and session dependent
part of dbus. The major goals I have in mind with this approach are:

- make the environmentvariables important for d-bus aware applications available;
- make sure the dbus sessionpart is not started more than once for a single user;
- make sure the dbus sessionpart is stopped when a session of a user ends;

I assume the user logs in with KDM, the loginmanager for KDE 3.5. The construction could very well used
with other loginmanagers (XDM, GDM) as well.
KDM has the ability to run scripts at the beginning of a session (at startup),
and at the end (reset). One of them can start (and stop) the dbus session part.

1. KDM: the files

KDM uses some files to start and stop:

. Xstartup
run as root, after a user succesfully logs in.

. Xsession
runs with permissions of the authorized user, to start the desired session (KDE).

. Xreset
run as root, after the user session has ended.

Where Xstartup is the place to start things up, Xreset is the place to undo these
commands.

The files in these directories must be accessible for every ordinary user:
therefore the permissions are 755.
All scripts in these directories should have the same permissions: 755.

Every user should be able to execute the script, but only root is able to
modify them.

1. Starting the sessiondaemon of dbus and make the environmentvariables available

The dbus package is split up in two parts: one systemwide part and one
for (each) session/user. The systemwide part (a daemon) is started at boottime,
with special privileges of a dedicated user. The sessionwide part (also a daemon)
has to started when a session for a user begins, and stopped when the session ends.

The construction with kdm I'm using here is ideal for this. One script in the
startup directory to start the sessiondaemon for a user, running with the privileges
of that user, and one in the reset directory an other script has to stop that daemon.

But is not so simple as that. Some variables (DBUS_SESSION_BUS_ADDRESS and
DBUS_SESSION_BUS_PID) have to be available in the environment to every application
which works with dbus. IMHO the setting of these variables should go in the
bash-startupscripts. Then whatever script or application you're running, these
variables are set to the right value.

1.1 About the startupfiles of Bash

The sessiondaemon of dbus creates a file which contains the environmentvariables.
As stated above this file should be read (sourced) by bash when it starts for this user.

When bash is started by "login" as an interactive login shell, it reads /etc/profile
and ~/.bash_profile. Bash is also started by "kdm", and the files /etc/profile
and ~/.bash_profile are sourced.

My idea is to store the output of the command

dbus-launch --auto-syntax

in the file

$HOME/.dbus-session

This file is "sourced" when bash start. This happens not automatically, but you
will have to add the following script to /etc/profile.d :

This script, executed by KDM at startup will start the dbus session daemon for this user,
and will create the .dbus-session file in the homedirectory of this user, containing
all the dbusvariables.
It will only do this when dbus is not already running for this user.

Now when bash starts at login, it reads (sources) this file.

As you can see, I've split the start of dbus up into two parts:
- dbus-session-start.sh, runs when a (kdm)session starts
- .dbus-session, sourced when a (bash)session starts, could be sourced multiple times

Futher, I use the --auto-syntax parameter, where I assume Bash is used. So I could
use here --sh-syntax, but it works.

And Sudo is needed to run dbus-launcher as the user who's logging in, cause KDM runs this script as root.
(actually the script checks for the id of the account running this script. It is root (id = 0) then sudo is used to
change to the user starting a session. When the id and the id of the user logging in are the same, nothing has to be done.

2.4 One user is more than one time logged in

For most of the situations this construction is good enough. Most users
have one session at a time. Now what happens when a user has more than
one sessions at the same time? Is it nessacary to start the sessionpart
of dbus for every session, or is one instance sufficient?

This construction does not allow more than one dbus-daemon per user.
I think that should be good enough.

CHANGELOG:

[2006-01-18]
* Initial howto
[2006-07-18]
* Changed the bash scripts
[2006-09-09]
* add check to see dbus-daemon is already running for this user
and the information found in .dbus-session is right