Substantially based on a patch by Matthias Clasen <mclasen@redhat.com>
kqueue implementation by Joe Marcus Clarke <marcus@freebsd.org>
Previously, when we detected a configuration change (which included
the set of config directories to monitor for changes), we would
simply drop all watches, then readd them.
The problem with this is that it introduced a race condition where
we might not be watching one of the config directories for changes.
Rather than dropping and readding, change the OS-dependent monitoring
API to simply take a new set of directories to monitor. Implicit
in this is that the OS-specific layer needs to keep track of the
previously monitored set.
The reload handling for activation simply dropped all knowledge
of pending activations, which was clearly wrong. Refactor things
so that reload only reloads directories, server address etc.
Based on a patch originally from Matthias Clasen <mclasen@redhat.com>
(Commit message written by Colin Walters <walters@verbum.org>)
A current Fedora goal is to convert projects to libcap-ng which
more easily allows dropping Linux capabilities. For software
which also links to libdbus, it's problematic to link against
libcap as well.
Though really, libdbus should have never linked against libcap
in the first place, which is another thing this patch changes
by moving the libcap-using bits out of dbus/ and into bus/.
https://bugzilla.redhat.com/show_bug.cgi?id=518541
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>
In practice, ay seems to be used mostly for binary data (in which case,
hex output is fine) or for Unix file paths (because they may be
non-UTF-8) and similar human-readable strings. So let's print the latter
similarly to strings.
Previously dbus_message_iter_get_arg_type() was called twice: once in
the loop condition to update 'current_type', and once to check if the
loop will run again. This patch moves updating current_type to the end
of the loop body.
The timeout handling code subtracts the elapsed time from the timeout
each time a message is received, which drastically reduces the timeout
in circumstances such as service activation.
Correct so that the timeout is never modified, and the elapsed time
instead subtracted where necessary.
Signed-off-by: James Westby <jw+debian@jameswestby.net>
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
although their app had exited. As it turns out it was a missing
implementation of the method _dbus_fd_set_close_on_exec() for windows.
It's been tested with msvc2005, msvc2008, and mingw, and solves
all the unregistering issues on many kde apps.
In my informal studies of "normal" sets of match rules, only checking
match rules with the appropriate interface for the message reduces the
number that need to be checked by almost 100x on average (ranging from
halving for messages from the bus daemon, to a >200x reduction in many
cases). This reduces the overhead added to dispatching each message by
having lots of irrelevant match rules.
This is currently not a big deal, but will make more of a difference
once the set of match rules is partitioned by more features than just
the message type.
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>
