# dbus-broker: a D-Bus message bus written only for Linux, with a Rust toolchain in the build

> dbus-broker implements the message bus defined by the D-Bus specification and aims at high performance while staying compatible with the reference implementation. It is Linux only, needs a kernel of 4.17 or newer, and its release tags have not moved since 2025 even though the repository still receives pushes.

**bus1/dbus-broker** — Linux D-Bus Message Broker

- Repository: https://github.com/bus1/dbus-broker
- Website: https://github.com/bus1/dbus-broker/wiki
- Stars: 817 · Forks: 108
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/bus1-dbus-broker

## A message bus for the D-Bus spec, and only for Linux

dbus-broker is an implementation of a message bus as defined by the D-Bus specification. The README states its aim plainly: to provide high performance and reliability while keeping compatibility to the D-Bus reference implementation. That sentence contains the whole pitch and the whole risk.

Performance and compatibility are in tension in a bus, because the reference implementation is what every application on the system is tested against. A broker that is faster but subtly different in how it routes, activates or authenticates a message is a broker that produces failures in someone else's application. So the design goal is a drop-in replacement rather than a new bus, and the way that is verified is a test suite and a system test image, not a benchmark.

The other half of the description is the constraint that shapes everything: the project is exclusively written for Linux systems and makes use of many modern features provided by recent Linux kernel releases. This is not a portability question that was left open. It is a design decision to use kernel features that a portable broker could not, which is exactly where the performance comes from and exactly what would need rewriting on another operating system.

The practical audience is therefore Linux distributors and system integrators who control the image, plus container base images that need a broker that is not the distribution default.

## The requirement list says who this is for

The requirements section is unusually explicit, and it reads as a statement about the target platform.

The runtime needs are glibc 2.16 or newer, a Linux kernel of 4.17 or newer, and three optional libraries: libaudit 3.0 or newer, libcap-ng 0.6 or newer and libselinux 3.2 or newer. The optional security libraries are the interesting part, because they are the pieces that let the broker apply audit logging, capabilities and SELinux policy. Whether they are optional in the build sense or in the deployment sense is not spelled out, and it is worth asking which one you are in.

Separately, the compatibility launcher requires expat 2.2 or newer and systemd 230 or newer. The launcher is the piece that presents the old dbus-launch style interface on top of the new broker, so that programs written against the older interface keep working. The systemd requirement is a real floor: a distribution that does not ship systemd 230 or newer is outside the supported set for that path.

None of this is a complaint about the requirements, they are all reasonable numbers for a modern distribution. It does mean the project is aimed at a specific kind of target: a current Linux userland with systemd, a modern glibc, and a kernel new enough to have the features the broker wants to use.

## Four meson commands build, test and install it

The build system is meson, and the README says that in most situations the following commands are sufficient to build and install from source:

```bash
  $ meson setup build
  $ meson compile -C build
  $ meson test -C build
  $ meson install -C build
```

The order matters, and the third command is the interesting one. The test step is not an optional extra in a continuous integration pipeline, it is part of the documented build path. For a project whose central claim is compatibility with the reference implementation, a test suite that runs as part of a normal build is the mechanism that keeps the claim honest.

For anything beyond the defaults, the README points at meson_options.txt for the custom configuration options, and the repository also carries subprojects/ for vendored dependencies and a packit.yml for Fedora packaging.

The source tree itself is small in description: meson.build at the root, meson_options.txt beside it, then src/, test/, docs/ and subprojects/. The git sources are given in the README as well:

```bash
  Cloning over ssh: git@github.com:bus1/dbus-broker.git
  Cloning over https: https://github.com/bus1/dbus-broker.git
```

The bug reports go to the GitHub issues page, there is a wiki for the longer documentation, and the developer mailing list is on a Google group.

## A Rust toolchain in a C project, and why bindgen is there

The build-time requirements are where a C project stops looking like a C project:

```bash
  linux-api-headers >= 6.5
  meson >= 1.3
  pkg-config >= 0.29
  rust >= 1.84
  rust-bindgen >= 0.60
  dbus >= 1.10                (optional: only for tests)
  python-docutils >= 0.13     (optional: only for docs)
```

Rust 1.84 and rust-bindgen 0.60 are mandatory, and bindgen is the tool that generates Rust bindings from C headers at build time. Combined with linux-api-headers 6.5, that tells you the Rust side is not a separate tool, it is how the project consumes kernel interfaces, and the generated bindings are what connect the two languages.

The two optional entries are revealing about the project's priorities. The reference dbus 1.10 or newer is needed only for the tests, which is how a compatibility claim gets checked: you run the new broker against the old implementation and see that they behave the same. python-docutils is needed only for the documentation, which is the build of the D-Bus specification documents.

So the build needs a C compiler, a Rust compiler with bindgen, meson, pkg-config and recent kernel headers, and optionally the reference implementation and a documentation toolchain. That is a heavier build-time story than the four meson commands suggest, and it is the price of a project that mixes a C broker with generated Rust bindings against kernel APIs.

## The maintenance Makefile is a release checklist in code

The top level Makefile is not the build system, it says so itself, it is a collection of maintenance targets for easy development, and most of them describe how the release and test infrastructure is used.

The targets divide into three groups. There are the meson wrappers, meson-build and meson-test, which re-run the commands the README documents, plus meson-setup, which reconfigures the Meson setup. There are the analysis targets, coverity-scan to run a full analysis via Coverity and coverity-upload to upload the result. And there are the release targets, release-fedora, which prints a checklist for Fedora releases, and release-github, which prints a checklist for GitHub releases.

The last group is the interesting one for anyone assessing the project, because printing a release checklist from the build system is a deliberate choice. It means the steps for a release live next to the code rather than in a wiki page that drifts, and it means the person cutting a release has the list in front of them. The packit.yml file at the root ties that into Fedora packaging, and the REUSE.toml file and the LICENSES/ directory show that the licensing metadata is handled as a first class part of the tree, which matters for a project whose source is distributed in every Linux distribution.

The remaining targets cover testing at two levels: system-build builds the system test image and system-run runs it, and spec-build builds the specification as html. A system test image is the closest thing here to an integration environment, and it is where a claim about matching the reference implementation would be validated end to end.

## Where dbus-broker is the wrong tool

The first wrong fit is anything that is not Linux. The project states that it is exclusively written for Linux systems, and the requirement of a 4.17 or newer kernel is a sign of how modern kernel features are used rather than avoided. A team that needs one bus implementation across operating systems is looking at the reference implementation instead, and that is the real alternative here: the trade is between a broker optimised for one platform and one that is portable but slower, and the difference in approach is the whole point of the project.

The second wrong fit is a system without systemd 230 or newer, if the compatibility launcher matters to you. The launcher is what lets older style clients keep working, and it has its own dependency floor.

The third is a release cadence assumption. The tagged releases are v35 on 2023-12-20, v36 on 2024-04-12 and v37 on 2025-06-16, while the last push to the repository was on 2026-07-02. Commits are landing after the most recent tag, which is normal for a project with a development branch, but it means the artefact a distribution ships is not the same as the tip of the tree. The NEWS.md file in the repository is where that history is recorded.

The fourth is licensing. The project is under the GNU General Public License version 3 or later, with the SPDX identifier GPL-3.0-or-later and the copyright statement held by the D-Bus Broker Developers, and the AUTHORS file carries the details. A daemon that becomes part of a distribution is usually fine with that, but a team with a policy against GPL components should read the terms before shipping it. This is not legal advice.

The fifth is a false economy. The optional security libraries, libaudit, libcap-ng and libselinux, are where a broker earns its keep in a locked down image, and if none of them are in your build then a good part of the reason to run this broker instead of the default is missing. Check that the deployment actually uses them.

## Conclusion

dbus-broker fits a Linux distribution or container image that wants a D-Bus broker built for the modern kernel and is willing to take on the compatibility launcher and the optional security libraries. It does not fit a non-Linux platform, and it does not fit a team that needs a released, packaged artefact on a schedule it can plan around. Before adopting it, build it and run meson test against your own bus traffic, because the compatibility claim is the thing you are buying.

## FAQ

### What is dbus-broker?

It is an implementation of the message bus defined by the D-Bus specification, written for Linux systems only, with the stated aim of high performance and reliability while keeping compatibility to the D-Bus reference implementation.

### How do I build dbus-broker?

The meson build system is used, and the README says four commands are sufficient in most situations: meson setup build, meson compile -C build, meson test -C build and meson install -C build. Custom options are described in meson_options.txt.

### What does dbus-broker need at build time?

The build requires linux-api-headers 6.5 or newer, meson 1.3 or newer, pkg-config 0.29 or newer, rust 1.84 or newer and rust-bindgen 0.60 or newer, with dbus and python-docutils needed only for the tests and the documentation respectively.

### What are the runtime requirements for dbus-broker?

glibc 2.16 or newer and a Linux kernel of 4.17 or newer, plus optionally libaudit 3.0, libcap-ng 0.6 and libselinux 3.2. The compatibility launcher additionally needs expat 2.2 or newer and systemd 230 or newer.

### What licence is dbus-broker under?

It is under the GNU General Public License version 3 or later, with the SPDX identifier GPL-3.0-or-later and the copyright held by the D-Bus Broker Developers, and the AUTHORS file holds the details.

## Sources

- [bus1/dbus-broker on GitHub](https://github.com/bus1/dbus-broker)
- [Issues](https://github.com/bus1/dbus-broker/issues)
- [Project website](https://github.com/bus1/dbus-broker/wiki)
- [README](https://github.com/bus1/dbus-broker/blob/main/README.md)
- [Releases](https://github.com/bus1/dbus-broker/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bus1-dbus-broker