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
At previous, argv[0] is the full-qualified path of program, however, if
start dbus-launch failed, it will fall back to find one from $PATH,
while keep the argv[0] as the full-qualified path. So we'll get
misleading info from /proc or ps(1) about dbus-launch process.
One simple solution is just hard-code argv[0] to dbus-launch.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69716
Reviewed-by: Simon McVittie
It's least confusing if the two files have the same contents. systemd
already knows how to pick up our /var/lib/dbus/machine-id if it exists
and /etc/machine-id doesn't, but the converse is not currently true.
We should make it true, so that it doesn't matter what order
systemd-machine-id-setup and "dbus-uuidgen --ensure" were
invoked in.
In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
will *usually* - but not always! - run first, and the two files will
match. However, if you install systemd without dbus, and then install
dbus later, there will be a mismatch. With this change, it doesn't
matter which one is installed first: whichever one happens to come
first, it will generate the machine ID, and then the other one will
copy it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
xmlto is a shell script, it needs to be fed MSYSsy filenames.
This patch adds a cygpath invocation for filename conversion (autotools do
that automatically, for CMake you have to spell it out). Cygwpath is available
in MSYS2 (and Cygwin, obviously).
When cygpath is not available, use MSYS-specific pwd extension to get W32 path.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75860
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Leaving Nagle's algorithm enabled on the TCP transport leads to some
really long latencies (at least, during the first several messages).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75544
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This means we can drop our convenience copy of sd-daemon.[ch]. We're
checking for libsd-daemon anyway, to support journald and logind
integration.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71818
Reviewed-by: Lennart Poettering <lennart@poettering.net>
Autotools uses a versioned shared library name derived from libtool.
This patch adds a versioned shared library name to cmake builds for all
supported platforms. Binary compatibility for clients build against older
cmake generated binary packages of dbus is provided; on unix like os
with symbolic links and on Windows with a copy of the shared library.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74117
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[Add its source file to SOURCES: this test was previously relying on the
Automake feature that the default value of foo_bar_SOURCES is foo-bar.c. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73495
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The algorithm to collapse a subsidiary config file's data into the
master data structure forgot to examine this flag.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73475
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In general, I think developers running the tests would expect
them to terminate rather than hanging. Developers who want to debug
such an abort by attaching a debugger to a live process can still set
DBUS_BLOCK_ON_ABORT in the environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The new macros add_test_executables and add helper_executables provides a
platform independent way for specifing dbus test and service applications.
On native Windows and Linux/UNIX systems the test applications are
directly runable.
When cross compiling for Windows on Linux test applications could be
executed on the Linux host system with the help of wine and activated
binfmt_misc support for wine.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
