[GDBus] Reopening the session bus

[Simon McVittie]

On 09/04/15 07:57, Alberto Mardegan wrote:
>   I'm writing some tests in python, and I'm setting up a new D-Bus
> server for the session bus in each setUp() function, and I'm killing it
> at the end of each test case.

You might get on better if you did something more like this:

* securely create a temporary directory, let's say $tmp, and chmod it
  0700 (it could either be in /tmp or in $builddir)
* escape its path suitably for D-Bus addresses, let's say the result is
  $esc
* set DBUS_SESSION_BUS_ADDRESS=unix:path=$esc/bus in the tests'
  environment
* in setUp(), start a dbus-daemon with --address=unix:path=$esc/bus,
  using either "--fork --print-pid" or "--print-address" to ensure that
  it is ready to accept connections before proceeding
* in tearDown(), kill that dbus-daemon (with the background process's
  pid if you used --print-pid), waitpid() for it, and delete
  $tmp/bus
* on process exit, remove $tmp

> The server is started with dbus-launch

Whatever your question is, dbus-launch is rarely the right answer :-) It
tries to solve a lot of ad-hoc use cases with no clear overall design,
with the result that it solves them all badly.

For regression tests I strongly recommend either the newer
dbus-run-session(1), or running dbus-daemon yourself (which is what
dbus-launch and dbus-run-session both do behind the scenes).

dbus-run-session is basically telepathy-glib's old with-session-bus.sh
script, rewritten in C. You can use with-session-bus.sh if you need to
support old (< 1.8) dbus versions.

> This only works for the first test case being executed, because when the
> next test case calls g_bus_get(), it gets the same bus used in the
> previous test, even though the DBUS_* environment variables have been
> changed.

Right; changing those environment variables at runtime is not something
that would ever happen "in real life", so it's OK for GDBus to cache
them. The problem is that your tests are not behaving like "real life".

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>