What we are aiming for here is that `dbus-launch --autolaunch` will
exit with an error if it would have been unable to advertise the bus
in a way that will be picked up by other instances of itself, so that
we don't get a proliferation of autolaunched dbus-launch instances,
each with its own dbus-daemon, and none of them talking to the others.
However, we don't need to do that *immediately*: we can try to look for
an existing instance first. If we find one, then we can assume that
it's suitable for use, even if X11 autolaunching was disabled at
compile-time or if connecting to the X server failed at runtime. We
only need to bail out if we get to the point where we are ready to start
forking child processes.
This lets systemd users run `dbus-launch --autolaunch` to find a
systemd-managed dbus-daemon, even if X11 autolaunching is disabled.
When combined with the previous commit, it also lets macOS users run
`dbus-launch --autolaunch` to find a launchd-managed dbus-daemon.
Resolves: dbus/dbus#385
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were looking for an existing bus via
_dbus_lookup_user_bus(), meaning a user bus $XDG_RUNTIME_DIR/bus
(in practice this is managed by systemd --user, although in principle
there's nothing to stop other session frameworks from providing the
same thing).
_dbus_lookup_session_address() looks for an externally-managed
dbus-daemon in a more general way: on macOS it uses launchd, and on other
Unix it's a thin wrapper around _dbus_lookup_user_bus(). Let's try that,
so that macOS users can get their existing dbus-daemon from launchd.
This partially resolvesdbus/dbus#385, although initially only for macOS
users who have (unusually) enabled X11 autolaunching support.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This should avoid test failures under CMake in which the
dbus-daemon inherits an unwanted fd from CMake's test framework, causing
the close-on-exec check before executing activated services to fail.
The dbus-daemon now marks all fds that it inherits, except for its
stdin, stdout and stderr, to be closed on exec. For completeness, the
dbus-daemons run by dbus-run-session and dbus-launch also now inherit
stdin, stdout, stderr and the pipes used to communicate with their
callers, but nothing else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
stdout and stderr are close-on-exec and buffered, so we can't rely on
their buffers being empty. If we continue to execute application code
after forking (as opposed to immediately exec()ing), then the child
process might later flush the libc stdio buffers, resulting in
output that is printed by the parent also being printed by the child.
In particular, test-bus.log sometimes grows extremely large for
this reason, because this test repeatedly attempts to carry out
legacy activation.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
We only register signal_handler() for the three signals that we want
to handle as "kill dbus-daemon and exit", so there's no point in the
switch. Silence -Wswitch-default by removing it altogether.
The variable name got_fatal_signal and the verbose message are both
misleading, because actually this is a handler for multiple signals,
not just SIGHUP. Rename them to be generic.
Based on part of a patch from Thomas Zimmermann.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98191
Based on part of a patch from Thomas Zimmermann.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98191
This patch fixes warnings from '-Wsuggest-attribute=noreturn'. We cannot
enable it unconditionally as it would break libtool.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
In Debian bug <https://bugs.debian.org/829348>, lightdm appears to
have been starting dbus-launch with at least one of the three
standard fds 0, 1, 2 (stdin, stdout, stderr) closed. This resulted
in the dbus-daemon's epoll_create1() returning a fd less than 3.
Later, _dbus_become_daemon() replaces fds 0-2 with /dev/null. As a
result, a subsequent call to _dbus_loop_add_watch() for the reload
pipe resulted in calling epoll_ctl on the non-epoll fd pointing to
/dev/null, which fails with EINVAL, resulting in the dbus-daemon
exiting unsuccessfully.
Unix programs are not normally expected to behave correctly when
launched with the standard fds not already open; but at the same time,
X11 autolaunching means that dbus-launch (and hence the dbus-daemon)
can get started from an arbitrarily precarious situation.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97008
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Thiago Macieira <thiago@kde.org>
This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.
We read the machine UUID because it is needed to set the X atoms.
x11_init() assumes that the machine UUID (global variable) has been
set, either via read_machine_uuid_if_needed() or save_machine_uuid().
This is pretty tangled, but to make The Right Thing happen
automatically, we'd need to redo dbus-launch in terms of DBusError.
Reviewed-by: Will Thompson
Reviewed-by: Thiago Macieira
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
Signed-off-by: Simon McVittie <smcv@debian.org>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This provides backwards-compatible autolaunching behaviour, as long
as dbus-launch inherits the XDG_RUNTIME_DIR (which it presumably did
if it's going to work at all, since it must also have inherited the
DISPLAY). In particular, we go through the motions of starting the
dbus-daemon, so that we can start the "babysitter" process that will
maintain the X11 window to store the bus address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: decorate _dbus_lookup_user_bus with DBUS_PRIVATE_EXPORT so we
can still call it after fixing fd.o#83115; update cmake to match Autotools]
As a side benefit, this means that dbus-launch now understands
/etc/machine-id and not just /var/lib/dbus/machine-id.
Since machine_uuid comes out of libdbus allocated with dbus_malloc,
to avoid having to copy it from malloc-allocated to
dbus_malloc-allocated storage, it makes sense to change it to be
consistently dbus_malloc-allocated (particularly now that Bug #83115
has made use of internal symbols relatively painless). However, I'm
deliberately not changing the allocation model of any other strings
in dbus-launch right now; that's a larger yak-shaving exercise.
The timeline of events in dbus-launch's main process goes something like this:
* do initial X calls
[1]
* do some other stuff
* fork
(child process starts doing some other stuff)
* return "intermediate parent" pid from fork()
* obtain bus daemon pid from bus_pid_to_launcher_pipe
[2]
* do things that might include X11 calls or killing the dbus-daemon
Meanwhile, the "babysitter" child goes like this:
* return 0 from fork()
[3]
* obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe
[4]
* do things that might include X11 calls or killing the bus daemon
Before [1] or [3], the right thing to do about an X error is to just
exit. The current implementation called kill(-1) first, which is
undesirable: it kills unrelated processes. With this change, we
just exit.
After [2] or [4], the right thing to do is to kill the dbus-daemon,
and that's what the existing code did.
Between [1] and [2], or between [3] and [4], there is no correct thing
that we can do immediately: we would have to wait for the end of the
"critical section", *then* kill the dbus-daemon. This has not yet been
implemented, so this patch relies for its correctness on the fact that
there are no libX11 calls between those points, so we cannot receive
an X error between them.
dbus-launch deserves more comments, or a reimplementation that is easier to
understand, but this change is certainly better than nothing.
[Commit message added, summarizing reviewers' comments -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698
Reviewed-by: Simon McVittie
Reviewed-by: Thiago Macieira
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>
There are two build failure on NetBSD 6.1.1 with gcc 4.5.3, the first
one is char to int, warning treated as error. The second one is a mismatch
between format string and arguments.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69842
[adjusted commit message -smcv]
Reviewed-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
In a previous patch, it check SIGHUP for windows, however, in fact there
is dbus-launch-win.c supposed to be used on windows. So just use SIGHUP
unconditionally.
Also free memory on OOM, although this doesn't make much sense since
this is a oneshort program, rather than a daemon.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66068
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
From the department of "if it isn't tested, it doesn't work". I tried
compiling dbus without an assortment of optional features:
in_builddir ~/build/dbus/legacy ${MR_REPO}/configure \
--enable-developer --enable-maintainer-mode --enable-tests \
dbus_cv_sync_sub_and_fetch=no \
--disable-selinux \
--disable-inotify \
--disable-dnotify \
--disable-epoll \
--disable-kqueue \
--disable-launchd \
--disable-systemd \
--disable-libaudit \
--without-valgrind \
--disable-x11-autolaunch \
&& ...
and it resulted in -Wunused warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=64362
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
dbus-launch --exit-with-session attempts to scope the session length
to various things:
- if DISPLAY points to an X server, exit when the X session ends
- if stdin is a terminal, exit when end-of-file is reached
- if both are true, exit when one of them happens, whichever is first
- if neither is true, fail
These are not particularly useful semantics: if the session is scoped to
the X session, then the terminal from which dbus-launch was launched
is irrelevant. This also causes practical problems when dbus-launch
consumes characters from the terminal from which it happens to have
been launched (some display managers, like slim and nodm, run users' X
sessions with stdin pointing to the terminal from which the init daemon
happens to have started the display manager during boot, usually tty1
on Linux).
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
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 doesn't really do anything, because we're about to exit anyway, but
it placates static analysis tools.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=29881
Bug-NB: NB#180486
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
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>
