D-Bus broker to replace D-Bus daemon on a non-systemd Linux

[angel...@gmail.com]

Hi guys,

we have an embedded Yocto-based linux system which doesn't use systemd feature. AFAIK, D-Bus broker's dependency on systemd can be turned off (via meson configuration option), which is good. There is a D-Bus broker recipe on openembedded, which however requires systemd feature, but perhaps we can just comment that out. My question is, to replace the D-Bus daemon that we currently are using with D-Bus broker, is it sufficient to just introduce the packages built by dbus-broker recipe into our firmware image? The D-Bus daemon gets automatically replaced with D-Bus broker for all D-Bus message bus communications?

Thanks a lot for reply, and thanks for the good work :)

[David Herrmann]

Hi

(many of us are currently traveling due to devconf.cz 2019, so might
be some delay)

On Fri, Jan 18, 2019 at 12:31 PM <angel...@gmail.com> wrote:
> we have an embedded Yocto-based linux system which doesn't use systemd feature. AFAIK, D-Bus broker's dependency on systemd can be turned off (via meson configuration option), which is good. There is a D-Bus broker recipe on openembedded, which however requires systemd feature, but perhaps we can just comment that out. My question is, to replace the D-Bus daemon that we currently are using with D-Bus broker, is it sufficient to just introduce the packages built by dbus-broker recipe into our firmware image? The D-Bus daemon gets automatically replaced with D-Bus broker for all D-Bus message bus communications?
>
> Thanks a lot for reply, and thanks for the good work :)

Since several years now, dbus-daemon supports service activation. This
means that dbus-daemon spawns a specific service once the first
message is sent to it. In the past, this meant dbus-daemon had to
fork+exec the configured applications. It works fine until you need to
configure the environments applications are started in. Which is why
systemd-activation was introduced later on. dbus-daemon no longer
forks processes but simply tells systemd about activation of services,
which can then make full use of the systemd features.

In dbus-broker we split the launcher/controller from the main bus
implementation. In fact, the `dbus-broker` project is a pure
implementation of a bus according to the D-Bus specification. It has
no external dependencies at all and it can be run in full isolation,
as it needs no outside communication other than through dbus sockets.
However, such a pure implementation is not ready to be deployed. At
its minimum it needs a parent process that creates a listener socket
in the filesystem and passes it to dbus-broker, which then manages
that listener socket.

I recommend looking into the `dbus-broker(1)` and
`dbus-broker-launch(1)` man-pages shipped with dbus-broker. The core
dbus-broker process requires its parent to pass down a socket-pair
when executed. This socket-pair is then used to communicate between
dbus-broker and its parent. It allows making dbus-broker a
self-contained bus implementation, since all communication to the
outside is simply forwarded through this socket to the parent, and
left to the parent to decide what to do.
With `dbus-broker-launch` we provide a launcher that utilizes exactly
this controller-socket, and implements a bus implementation compatible
to the dbus-daemon reference implementation. That is, the launcher we
provide parses the XML configuration as defined by dbus-daemon, and
reacts to service-activation requests on the controller-socket by
forwarding them to systemd and activating the right systemd service.

However, we explicitly designed dbus-broker to allow for many
different controllers. `dbus-broker-launch` is just the
proof-of-concept (and also our drop-in replacement for dbus-daemon).
But we explicitly encourage people to deploy dbus-broker in other
scenarios and write their own controllers. `dbus-broker-launch` is
meant as drop-in replacement for dbus-daemon for system and user
buses. We do not intend to make it a full command-line compatible
replacement for the dbus-daemon binary. This allows us to simplify it
in many regards. For instance, systemd activation is mandatory for
dbus-broker-launch.

Long story short: dbus-broker has no systemd dependency. In fact, all
it requires is a standard C library and the linux kernel headers.
However, as upstream project we only provide a single integration
layer or controller so far, and this one is tailored for a specific
use-case. While it is possible to adapt it for more use-cases, we also
want to encourage people to write their own controllers, which can
then be much more easily adapted to specific scenarios.

Thanks
David