Ubuntu 26.10 Commits to Dbus-Broker, Seven Years After Fedora Made the Jump

Ubuntu 26.10 is set to replace the reference D-Bus implementation with dbus-broker, the high-performance drop-in that Fedora has shipped by default since Fedora 30 back in 2019. Ubuntu developer Alessandro Astone laid out the plan on the Ubuntu Discourse, confirming that the dbus-broker package moves to main, gets installed and enabled by default, while the classic dbus and dbus-daemon packages drop to universe.

If you have spent any time profiling service startup on a busy server, you already know why this is interesting. D-Bus is the local message bus that nearly everything talks through: systemd units signaling readiness, NetworkManager, logind tracking sessions, PolicyKit authorization checks, and on the desktop side basically every GNOME component. Every one of those messages passes through a broker process. The reference dbus-daemon, which traces its design back to the early 2000s, was never built for the message volume a modern system generates.

What Actually Changes Under the Hood

dbus-broker came out of the systemd orbit and was written with two goals: strict protocol correctness and throughput. It uses a single epoll loop, avoids the per-connection overhead the old daemon carries, and offloads policy decisions into a compiled form rather than re-parsing XML rules on every message dispatch. The classic dbus-daemon walks its policy ruleset for each method call, and on a system with hundreds of services that adds up.

The practical effect shows up in two places. First, raw message latency. dbus-broker's own benchmarking has historically shown round-trip times for method calls dropping to a fraction of what the reference daemon delivers under contention. Second, and more important for the homelab crowd, is behavior under load. When a system bus gets hammered, the old daemon's latency curve degrades badly because policy evaluation cost scales with the number of rules and connections. The broker keeps a much flatter profile.

Here is the rough shape of the difference, based on the kind of method-call throughput testing the project has published over the years:

Scenario	dbus-daemon (reference)	dbus-broker
Idle round-trip latency	baseline	similar, marginally lower
Method calls/sec, single client	moderate	noticeably higher
Throughput under many connections	degrades	stays flat
Policy evaluation cost	per-message XML walk	precompiled lookup
Memory per connection	higher	lower

The numbers vary wildly by workload, so treat the table as direction rather than gospel. The point is that the gap widens precisely when the bus is busiest, which is exactly when you care.

Why Ubuntu Took an Extra Seven Years

The delay was not inertia, it was integration debt. Two specific blockers held things up. GNOME's GDM relied on dbus-run-session, a helper shipped by the dbus-daemon package, and that dependency only got reworked in GNOME 49 so the display manager no longer needs the old package present. Until that landed, dropping dbus-daemon would have broken the login path.

The second blocker is more Ubuntu-specific: AppArmor and Snaps. Ubuntu's AppArmor integration mediates D-Bus traffic, and Snap confinement leans on bus policy to keep packaged apps in their lane. Swapping the broker meant making sure all of that mediation continued to function identically, since a confinement gap in the message bus is a real security concern, not a cosmetic one. That work is the reason this is landing in 26.10 rather than an earlier cycle.

{{IMAGE:2}}

What It Means for Your Boxes

For a headless server fleet, the upgrade should be invisible in the best way. Services keep talking over the same bus addresses, the API is unchanged, and the only thing you should notice is lower overhead during boot storms and heavy systemd activity. On machines that orchestrate a lot of short-lived units, the flatter latency curve is the tangible win.

If you maintain custom D-Bus policy files, this is the cycle to audit them. dbus-broker is stricter about malformed or ambiguous policy than the reference daemon, which has historically been forgiving of sloppy rules. A config that silently worked for years on dbus-daemon can surface as a denied call under the broker. Test your service activation paths before you roll 26.10 across anything you depend on.

The broader context is that the local IPC stack is in motion again. A new Rust-based BUS1 in-kernel IPC mechanism has resurfaced in discussions about where Linux message passing goes next, aiming to push the broker logic into the kernel entirely. dbus-broker is the userspace stepping stone in that lineage, so Ubuntu adopting it now also aligns the distribution with the direction the upstream developers have been steering toward for the better part of a decade.

For benchmark-minded admins, 26.10 is worth a controlled test once the interim release is available. Spin up a VM, run your normal service mix, and measure boot-to-ready time and bus method-call latency before and after. The change is one of those quiet infrastructure swaps that pays off across thousands of operations you never think about, and it finally puts Ubuntu on the same footing the Fedora side has enjoyed since 2019.