This means the bus test can use them without needing
dbus-message-private.h, reducing its view of message internals.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
This makes it a bit clearer what's going on.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
When used with init systems such as systemd (where PID files are
redundant) this allows us to disable PID files even if a path is
configured for them in the normal bus configuration files.
Make use of this new switch in the systemd unit file.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45520
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In practice, it never works, because the activation helper doesn't
respect environment variables for security reasons.
If you want to vary the search path, alter system.conf instead, to
replace or augment <standard_system_servicedirs/> with your preferred
search path.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21620
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
To optimize startup a bit, drop machine UUID generation from the unit
file. Since a while D-Bus was already capable of making use of the
/etc/machine-id file, which is guaranteed to exist on systemd systems
(since the first released versions already), hence there's no need to
ever generate a D-Bus specific machine ID.
In times where userspace takes < 800ms to boot up getting rid of this
process optimizes boot time further.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45520
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Someone seems to have merged part of master into 1.4. Again. Let's go
back to the "last known good" point (the branch-point of some 1.4
branches I had locally), then we can cherry-pick the changes that
should have gone in.
In Unix, the tests listened on both debug-pipe (which is a socketpair,
or a TCP emulation of socketpair on Windows) and a Unix socket.
In the Windows port, the tests were hard-coded to listen on a particular
port, which allowed the dispatch test to connect to that port, as long
as no two tests ran simultaneously (which I don't think was ever guaranteed -
make -j can violate this). That's valid out-of-process, and also
fully-specified, so they only needed one <listen> directive, so the
CMake input only had one.
To make the tests work under CMake on Unix, there was a hack: the string
substituted for the content of the <listen> directive contained
</listen><listen> to get the other address in, which is pretty nasty.
Instead of doing that, I've made both build systems, on both Unix and
Windows, use both debug-pipe and a more normal transport (Unix or TCP).
debug-pipe has a Windows implementation and it's used in
dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
hard-coded rather than being a configure parameter (there's no reason
to vary it in different builds), and I used TEST_LISTEN as the name of the
Unix/TCP address, because it's a "vague" address (no specific Unix path, no
TCP port), that you can listen on but not connect to.
This in turn means that we can merge the Autoconf .in and CMake .cmake
files, similar to Bug #41033.
You might wonder why I've kept debug-pipe. I did try to get rid of it, but
it turns out that the tests in dispatch.c rely on
dbus_connection_open_private() not blocking, and normal socket
connections block on connect(). Until we fix that by adding an async
version of dbus_connection_open_private(), it won't be safe to have a
test like dispatch.c that "talks to itself", unless it uses a transport
as trivial as debug-pipe in which neither end has to block on the other.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
Since 1.4.4 (commit 75cfd97f) this function always returned FALSE. As far
as I can see this was actually harmless, because both of its callers
ignore any error that is not NoMemory (and treat it the same as success).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
If we're going to return FALSE for this (which has apparently always
been the case), then we should set an error properly.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
In commit ab7b3f9, Ralf notes that handle_reload_watch() is (in principle)
cross-platform. However, there's no way to trigger it on Windows, because
nothing ever writes to the pipe. Make the entire pipe-to-self trick
Unix-specific instead.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40002
This patch ensures the daemon process doesn't inherit any supplemental
groups for the root user from an administrator login via an init
script.
This is only an issue for pre-systemd systems.
https://bugzilla.redhat.com/show_bug.cgi?id=726953
On OSs with abstract sockets, this is close enough. On OSs without
abstract sockets, this results in failing to clean up Unix sockets
in /tmp if someone has sent us thousands of SIGHUP signals since we
last entered the main loop - I think that's acceptable.
The reload pipe should never get closed, but if it is for some reason,
we want a SIGTERM after that to cause an exit too.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38656
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Signals are POSIX but not ISO C, so guard it with DBUS_UNIX.
dbus-sysdeps-util-win doesn't actually implement _dbus_set_signal_handler
anyway, so not compiling this code on non-Unix seems more honest.
Backported to dbus-1.4, originally part of commit c7ef3ead55.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33336
Reviewed-by: Thiago Macieira <thiago@kde.org>
This patch ensures the daemon process doesn't inherit any supplemental
groups for the root user from an administrator login via an init
script.
This is only an issue for pre-systemd systems.
https://bugzilla.redhat.com/show_bug.cgi?id=726953
Everything in this directory is statically linked to libdbus-internal,
so we can make -DDBUS_STATIC_BUILD global. Also, merge INCLUDES into
AM_CPPFLAGS (it's an older name for the same functionality).
