It's not expected to have to manually SIGHUP the bus after installing
a new .service file. Since our directory monitoring is already set
up to queue a full reload which includes service activation, simply
monitor the servicedirs too.
https://bugs.freedesktop.org/show_bug.cgi?id=23846
Internal setup of session bus type was bound to the presence of the --session
command line parameter which prevents to use the --config-file parameter for
session bus setup.
We were incorrectly passing NULL for a DBusList when the usage expected
is a pointer to a NULL DBusList pointer. Also during dbus_shutdown
we need to actually close the inotify fd, and remove our watch.
Move the shutdown handler out of bus.c and into inotify where we
can do all of this cleanly.
(cherry picked from commit 90fe96b187)
_dbus_change_to_daemon_user moved into selinux.c for the --with-selinux
(and audit) case because that's where all of the relevant libcap headers
were being used. However in the --disable-selinux case this didn't
compile and wasn't very clean.
If we don't have libaudit, use the legacy direct setgid/setuid bits
we had before in dbus-sysdeps-util-unix.c.
_dbus_change_to_daemon_user moved into selinux.c for the --with-selinux
(and audit) case because that's where all of the relevant libcap headers
were being used. However in the --disable-selinux case this didn't
compile and wasn't very clean.
If we don't have libaudit, use the legacy direct setgid/setuid bits
we had before in dbus-sysdeps-util-unix.c.
We were incorrectly passing NULL for a DBusList when the usage expected
is a pointer to a NULL DBusList pointer. Also during dbus_shutdown
we need to actually close the inotify fd, and remove our watch.
Move the shutdown handler out of bus.c and into inotify where we
can do all of this cleanly.
_dbus_get_current_time() is used for timeouts, but uses gettimeofday(), which
relies on the wall clock time, which can change. If the time is changed forwards
or backwards, the timeouts are no longer valid, so the monotonic clock must be used.
https://bugs.freedesktop.org/show_bug.cgi?id=25624
Signed-off-by: Colin Walters <walters@verbum.org>
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.