Re: [GDBus] Reopening the session bus
Simon McVittie <simon.mcvittie-ZGY8ohtN/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Organization | Collabora Ltd. |
| Message-ID | <[email protected]> |
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/> _______________________________________________ dbus mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dbus