Ubuntu is preparing one of those deep system changes that should leave almost no visible trace in everyday use. Starting with Ubuntu 26.10, dbus-broker will become the default implementation for the internal communication previously handled by dbus-daemon, a historic component of the Linux desktop and many system services.

For ordinary users, there will be no new application, different menu, or configuration to learn. The computer will continue connecting to Wi-Fi, detecting USB drives, adjusting screen brightness, and launching programs just as before. The change takes place several layers below the interface and aims to improve the reliability, performance, and responsiveness of infrastructure that has quietly supported Linux systems for more than two decades.

Ubuntu 26.10 and dbus-broker: the essentials in 20 seconds

Ubuntu will replace dbus-daemon with dbus-broker as the default D-Bus implementation.
The change will affect both the system bus and each user’s session bus.
It will apply to new installations and systems upgraded to Ubuntu 26.10.
Applications will continue using the same D-Bus protocol.
Existing configuration files and access policies will remain compatible.
dbus-broker uses an asynchronous, event-driven architecture.
Canonical expects improvements in performance, resource accounting, reliability, and handling large numbers of connections.
Adoption was delayed by GDM dependencies and the need to match AppArmor and Snap confinement support.
GNOME 49 removed the dependency that had been blocking the transition.
Most users will not need to do anything.

D-Bus is an inter-process communication system. It acts as an intermediary that allows applications and services to exchange messages without requiring a custom integration between every individual component.

When the desktop displays a new wireless network, detects an external drive, checks the battery level, or asks a system service to perform an operation, part of that communication will often travel through D-Bus. There is a system bus for shared services and a separate session bus for each user.

Ubuntu is therefore not abandoning D-Bus. It is replacing the program that acts as the broker. The protocol remains the same, and applications do not need to know whether dbus-daemon or dbus-broker is running behind the scenes.

Component	Up to Ubuntu 26.04	From Ubuntu 26.10
Protocol	D-Bus	D-Bus
System bus	`dbus-daemon`	`dbus-broker`
Session bus	`dbus-daemon`	`dbus-broker`
Configuration and policies	D-Bus compatible	Preserved
Application changes required	None under normal conditions	None under normal conditions
Broker architecture	Historic reference implementation	Asynchronous, event-driven design
Default package	`dbus-daemon`	`dbus-broker`

Why Canonical is replacing dbus-daemon after so many years

dbus-daemon is the reference implementation and has proved remarkably stable. It has supported GNOME, KDE, and many of the services found in a modern Linux system for years. The reason for the change is not that it suddenly stopped working, but that it was designed for a time when the number and complexity of system communications were lower.

Modern computers run more services, sandboxed applications, remote sessions, and simultaneous workloads. D-Bus has also moved beyond the desktop and is used on servers, embedded systems, and connected devices. Canonical believes the traditional implementation has greater difficulty meeting current requirements for performance and reliability.

dbus-broker first appeared in 2017 as a new implementation compatible with the D-Bus specification, designed specifically for Linux and built around modern kernel capabilities. Its developers wanted to address structural problems that were difficult to fix in dbus-daemon without changing behaviours on which many existing applications already depended.

Those issues included memory usage that was difficult to contain when a client consumed messages too slowly, global data structures that could become bottlenecks, and specific situations in which a message might be discarded without the sender or receiver being clearly informed.

That final point requires some nuance. It would not be accurate to say that dbus-broker can “never lose messages” under any circumstances. Its design aims to prevent expected traffic from disappearing silently and to assign responsibility more clearly when resources are exhausted. Its own documentation still allows certain messages explicitly marked as not requiring a reply, as well as some unsolicited signals, to be dropped for compatibility reasons.

The improvement lies in the way problematic situations are handled. For replies and expected signals, dbus-broker tries to guarantee delivery. If sufficient resources are unavailable, it may disconnect the receiver cleanly rather than continuing in an ambiguous state. It also distinguishes between message types when deciding which participant should be charged for resource use.

Its accounting model prevents a process from bypassing certain limits simply by opening many connections. Resources are attributed to the corresponding user, and each participant receives a controlled share of the input queues.

The asynchronous, event-driven architecture also reduces dependence on global structures and allows the broker to handle many simultaneous requests more effectively. The goal is not necessarily to make the desktop visibly faster when opening a window, but to make the communication layer behave more predictably under load or when a client misbehaves.

Canonical is not the first distributor to make this move. Fedora adopted dbus-broker as the default in Fedora 30, released in 2019. Ubuntu waited several more years because it had two specific obstacles to resolve.

The first was GDM, the login manager that displays GNOME’s sign-in screen. GDM depended on dbus-run-session, a tool supplied by the dbus-daemon package, to create isolated buses for different greeter instances, such as the local login session and remote desktop connections.

GNOME 49 changed this behaviour and removed the direct dependency. Once GDM no longer required dbus-run-session, the last major blocker among Ubuntu’s core packages disappeared.

The second obstacle was AppArmor. Ubuntu uses it to restrict which D-Bus messages can be sent or received by particular packages, sensitive services, and Snap applications. Replacing the broker without preserving those restrictions would have introduced a security regression.

AppArmor integration in dbus-broker required years of work before reaching coverage comparable to dbus-daemon. Ubuntu 26.10 will include additional fixes to align the two implementations and reduce differences in the enforcement of security policies.

What changes for users and administrators

For most people, nothing visible changes. Canonical describes dbus-broker as a drop-in replacement: it uses the same protocol, accepts the same configuration files, and applies the same bus policies. Applications, desktop environments, and Snap packages should continue to work without modification.

Ubuntu will install dbus-broker by default and move it into the Main repository, where Canonical provides a higher level of maintenance. The dbus and dbus-daemon packages will move to the Universe repository.

The systemd units supplied by the new package will use aliases to replace the traditional services. Even if dbus-daemon remains installed because of an external dependency, dbus-broker will take priority for providing the system and user buses.

Administrators should still review a few special cases:

internal tools that invoke dbus-daemon directly;
integration tests that depend on dbus-run-session;
third-party packages with an explicit dependency on the older implementation;
custom AppArmor policies for D-Bus interfaces;
scripts that look for specific process or unit names;
monitoring systems that expect to find dbus-daemon running.

These exceptions should not be confused with general incompatibility. The entire purpose of the change is to allow applications to operate through the D-Bus protocol without caring which broker implements it.

Canonical also allows the new setup to be tested before Ubuntu 26.10. Ubuntu 26.04 LTS users can install the package and reboot:

sudo apt install dbus-broker
sudo reboot

The version available in Ubuntu 26.04 is very similar to the one planned for 26.10, although the later release will include additional fixes. Canonical recommends reporting any problems so that they can be addressed before the broader rollout.

There is also a rollback path for test environments. Users can reinstall the traditional package, disable dbus-broker for the system bus and user sessions, and reboot:

sudo apt install dbus
sudo systemctl disable dbus-broker
sudo systemctl --user --global disable dbus-broker
sudo rebootCode language: PHP (php)

The ability to revert will be useful when determining whether a failure is genuinely caused by the new broker or by another change introduced in Ubuntu 26.10.

This replacement is a good example of a largely invisible part of operating system maintenance. Mature infrastructure does not always improve through headline features designed for launch presentations. Sometimes it improves by replacing an old component, preserving all its interfaces, and ensuring that millions of users do not need to know the change has happened.

dbus-daemon is not disappearing from the D-Bus project, nor does it suddenly become unsuitable for every system. It remains the reference implementation and supports platforms that dbus-broker, which was created specifically for Linux, does not attempt to serve.

Ubuntu has chosen a tool better suited to its current architecture. If the transition works as planned, the clearest sign of success will be the absence of visible incidents: the same applications, the same features, and a more resilient communication layer underneath.

Frequently asked questions

What is D-Bus in Ubuntu?
It is an inter-process communication system. It allows applications, the desktop environment, and system services to exchange commands and notifications.

Will I need to change any settings after installing Ubuntu 26.10?
Under normal circumstances, no. dbus-broker uses the same protocol, policies, and configuration files as the previous implementation.

Is Ubuntu completely removing dbus-daemon?
It will no longer be the default and will move to the Universe repository. It may remain installed when an external tool still depends on it explicitly.

Can I test dbus-broker on Ubuntu 26.04 LTS?
Yes. Canonical allows it to be installed through APT and recommends testing it on non-critical systems to identify compatibility issues before the general transition.