Getting started

First steps with D-Bus

Most desktops running D-Bus have the reference implementation installed. If the following example fails, try with a more common desktop and distribution.

Introduction

D-Bus introduces a few concepts for inter-processes communications.

Here is one way to make a method call from the shell:

dbus-send                     \
  --system                    \
  --type=method_call          \
  --print-reply               \
  --dest=org.freedesktop.DBus \
  /org/freedesktop/DBus       \
  org.freedesktop.DBus.ListNames

👉 You should get a list of unique and well-known names printed. Those are broadly speaking registered participants (connections and services) to the bus.

By reviewing the dbus-send¹ arguments, let us introduce the main concepts:

• --system: connect to the system bus. A bus is a space for different services (or processes) to communicate. The system bus is unique per host and should always be available.

• --type=method_call: send a method call message (other messages exist, such as replies, signals).

• --print-reply: wait for the reply, print it.

• --dest=org.freedesktop.DBus: specify the destination for the message. It may be a unique name (ex :1.57, identifying a specific connection), or a well-known name which is resolved to a specific connection. You may think of it as DNS resolution, mapping the URL server address to an IP.

• /org/freedesktop/DBus: the object path, identifying a resource within the destination. You can also make the analogy with an HTTP path.

• org.freedesktop.DBus.ListNames: the interface (org.freedesktop.DBus) & method (ListNames) to call.

Explore

D-Bus is most often used with a bus. The bus and services offer introspection and monitoring.

You can explore the bus with a UI tool like d-feet.

You can watch for messages on the bus with a monitor. For example, to watch for the name activity on the bus, you may run gdbus²:

gdbus monitor --session -d org.freedesktop.DBus

Activation on demand

D-Bus offers a mechanism to start services only when needed. Thus, some services (and processes) may not be running before you actually call or request them. Read more about it in the specification.

On buses and p2p

Two buses are commonly available to a user: the system and the session buses. When appropriate, private buses can also be running. They can be specific to an application or a context.

But D-Bus is not limited to a bus topology. You may have processes talking to each other directly without going through a bus. This peer-to-peer mode may allow better performances or security. It may be a better design for your solution, and you may benefit from the available protocol implementations to make your processes communicate.

Read also

The API Design Guidelines for best practices.

The python.org wiki on D-Bus, with simple Python code examples.

The project wiki is full of resources and documents (sometime a bit outdated).

Edit this page on Gitlab