By default, D-Bus is presented in most popular distributions because some applications may require it. Sometimes we can see error messages in logs and notice “dbus” in it. We can see its dbus-daemon, which loads when system starts:
user 656 0.0 0.0 16744 3992 ? Ss 08:04 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
So, what is D-Bus for? What functions does it perform? Why is it so important in Linux? Let’s get started.
What is D-Bus?
D-Bus translates as Desktop Bus. It is a thing that perform the messaging between applications under X system environment. Thus, an application can receive information from other applications. For example, where is the user’s cursor placed on.
D-Bus consists of daemon, API and client utility (dbus-send). An application that wants to work with it need to register own service in dbus daemon. Each application can freely messaging, therefore it is called a bus. After registration, the application gets its own address on the bus. So, this is how it works. To send a message, the application must provide the recipient address. And there may be several recipients. Each application can send messages to others and receive incoming.
This mechanism allows applications to subscribe to any changes in the system. Connecting new hardware, resizing windows, change settings and many others. D-bus is standardized by freedesktop.org, so it guarantees compatibility. Services can run when the message arrives and doesn’t work in the background, so it is very effective.
How many buses does D-bus contain?
By default D-Bus contains two buses. The first is called system bus. The second one is called user bus.
System bus performs messaging between system applications, which work with essential things such as devices or system settings.
User bus is created for each user. It performs messaging between simple application that the user has launched.
Objects in D-Bus
When the application is registered it receives own object. In D-Bus, each object has a unique name. So, applications can communicate using their objects. Access to objects occurs like with files in directories.
The path to the object consists of the name of the service and the name of the object itself. We can look at it. The following command shows us current working objects under user session:
dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames ... string "org.freedesktop.systemd1" string "org.PulseAudio1" string "org.fcitx.Fcitx-0" // This is input method framework for writing in Japanese, Chinese
Object org.freedesktop.systemd1 consists of org.freedesktop service name and systemd1 object name.
We can take a look at system objects with the following command:
dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames ... string "org.freedesktop.login1" string "org.freedesktop.timesync1" string "org.freedesktop.systemd1"
There are may be interfaces that are inside objects. In following example object is portal and Fcitx its interface.