We don't want the regression tests' "session" getting mixed up in
system-wide "sessions". This doesn't actually matter yet, but it is
likely to matter in future.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[merged with earlier line-wrapping of TESTS_ENVIRONMENT -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are two ways to find the dbus-daemon for testing. The first one is
defined as string at compile stage and the second one is export it from
test environment.
The first way has limitation that after defined, it's static string, so
it's impossible to run installable check. So let's unify to the second
way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
[added missing "}" -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In practice, it won't; other forms of autolaunch (like Mac OS launchd)
might, but we can't really assert either way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40352
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[amended to reinstate use of dbus/dbus-sysdeps.h which was removed
by 412538b3b9 -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It's sufficiently portable that GLib has an equivalent, and I really
don't want to have to either open-code it in dbus-run-session or
link dbus-run-session statically. We have enough statically-linked
rubbish already.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Reviewed-by: Colin Walters <walters@verbum.org>
This lets them be thread-safe by default, at the cost that they can
now fail.
init_uninitialized_locks() and init_global_locks() must now both
reimplement the equivalent of _dbus_register_shutdown_func(), by using
_dbus_platform_rmutex_lock() on the same underlying mutex around a call
to _dbus_register_shutdown_func_unlocked().
This is because if they used the usual _DBUS_LOCK() API (as
_dbus_register_shutdown_func() does), it would automatically try to
initialize global locking, leading to infinite recursion.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Anas Nashif <anas.nashif@intel.com>
...except for CheckForAbstractSockets.c, which runs before config.h is
generated, and sd-daemon.c, which is externally-maintained.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
As with the optional test-dependencies on GLib and dbus-glib, we make this
a hard dependency if --enable-tests[=yes], but not if --enable-tests=auto.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37847
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
This is the library used by tests that link libdbus-internal and DBusLoop.
By linking libdbus-internal into it, we can avoid having to repeat that
dependency all over the place - libtool and cmake both know how to follow
recursive dependencies.
In cmake, also use libdbus-testutils for more tests, in preference to
repeating its source files.
These tests get everything they need from the public or internal API of
libdbus-internal.la, and libtool knows how to pull in libraries'
dependencies, so we don't need explicit linking.
spawn-test and break-loader don't actually need test-utils.[ch]
either.
DBUS_ENABLE_X11_AUTOLAUNCH obviously requires DBUS_BUILD_X11. However,
the converse is not true.
If DBUS_BUILD_X11 is defined, dbus-launch will be able to connect to
the X server to determine when the session ends; most distributors will
want this, but it can be disabled with the standard Autoconf option
--without-x.
If DBUS_ENABLE_X11_AUTOLAUNCH is *also* defined, dbus-launch and libdbus
will be willing to perform autolaunch. Again, most distributors will want
this, but it can be disabled with --disable-x11-autolaunch.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19997
Reviewed-by: Colin Walters <walters@verbum.org>
This fixes a race condition: the server exits while the client continues
to the next iteration. If the server wins, the test passes. If the client
wins, it sends a message to the dying service, never gets a reply, and the
test fails.
My branch to refactor the main loop for fd.o #23194 seems to make the
client more likely to win this race, resulting in intermittent test
failures.
This is an instance of the general problem described by fd.o #11454.
This reverts commit 4626b40560.
test-autolaunch works fine in non-launchd environments (and non-X11
environments, based on a quick test passing enable_x11=no to configure).
On the contrary: this commit *broke* the build on non-launchd
environments, because test/name-test/run-test.sh still tried to run this
test even if it hadn't been built.
* test/name-test/test-autolaunch.c: New file,
unsets DBUS_SESSION_BUS_ADDRESS so we should
fall back to autolaunch:.
* test/name-test/run-test.sh: Run it.
* test/name-test/Makefile.am: Build it.
This test, while extensive, has the serious flaw of effectively
spinning on _dbus_connection_do_iteration_unlocked. Any tests
like this should be using the internal DBus mainloop, which
I don't have time to port it to before doing a release.
A variety of system components have migrated from legacy init into DBus
service activation. Many of these system components "daemonize", which
involves forking. The DBus activation system treated an exit as an
activation failure, assuming that the child process which grabbed the
DBus name didn't run first.
While we're in here, also differentiate in this code path between the
servicehelper (system) versus direct activation (session) paths. In
the session activation path our error message mentioned a helper
process which was confusing, since none was involved.
Based on a patch and debugging research from Ray Strode <rstrode@redhat.com>
A variety of system components have migrated from legacy init into DBus
service activation. Many of these system components "daemonize", which
involves forking. The DBus activation system treated an exit as an
activation failure, assuming that the child process which grabbed the
DBus name didn't run first.
While we're in here, also differentiate in this code path between the
servicehelper (system) versus direct activation (session) paths. In
the session activation path our error message mentioned a helper
process which was confusing, since none was involved.
Based on a patch and debugging research from Ray Strode <rstrode@redhat.com>
* test/test-service.c (handle_delay_echo, path_message_func): Add a
variant of the Echo method which sleeps for a short time.
* test/name-test/test-pending-call-timeout.c: Run tests with default,
specified and infinite timeout to make sure we get the reply.
* test/name-test/run-test.sh: Run the new test
* test/name-test/Makefile.am: Build the new test
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
(cherry picked from commit c1f165261a)
* test/test-service.c (handle_delay_echo, path_message_func): Add a
variant of the Echo method which sleeps for a short time.
* test/name-test/test-pending-call-timeout.c: Run tests with default,
specified and infinite timeout to make sure we get the reply.
* test/name-test/run-test.sh: Run the new test
* test/name-test/Makefile.am: Build the new test
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
This patch makes various things that should be static static,
corrects some "return FALSE" where it should be NULL, etc.
Signed-off-by: Colin Walters <walters@verbum.org>
This patch makes various things that should be static static,
corrects some "return FALSE" where it should be NULL, etc.
Signed-off-by: Colin Walters <walters@verbum.org>
