How to interact with D-Bus from an Elixir app?

Anyone have experience interacting with DBus from within an elixir app? I’m trying to think of the best way to make the app’s internal state available to other services and setting a DBus property seems like one way to do so. I just can’t find much information about doing so from within elixir/erlang.


There is this project

But I haven’t used it yet.

1 Like

I haven’t done this in Erlang/Elixir, but I got smacked real bad once because there’s a difference between the system and session dbus.

Here are some notes in case you are unfamiliar.

There are two different dbus types. There is a “system” dbus which usually runs under /run/dbus/system_bus_socket (or some close by location) as user dbus and is typically not the source of problems.

However, there is generally confusion when a program doesn’t work. That’s becaues the [system] dbus is running, but the program can’t find [user] dbus.

The user dbus runs as your regular user account and does not have a well-known location to listen. Usually, programs needing the user-dbus will read the location from environmental variable DBUS_SESSION_BUS_ADDRESS.

Note you might think that launching your program with dbus-launch is a good idea because it will then easily find dbus. This thinking will get you in a world of hurt because now there will be three separate dbus interfaces running, none of which speak to the other.

Good luck in your quest. :crossed_fingers:


We use dbus from elixir on our Elixir Nerves project (running on raspberry pi3).
We use it to control different omxplayer processes.

No special library involved, we have a DBusServer genserver managing the state of our daemon. We use the Elixir Port API to monitor its state

We start the daemon like this:

def start_daemon do
  cmd = "dbus-daemon --session --nofork --print-pid --print-address"
  port ={:spawn, cmd}, [:binary])

  receive do
    {^port, {:data, output}} -> {:ok, port, output}
    @start_timeout -> :error

we parse the command output with this code to extract its pid

defp parse_command_output(output) do
  pid_match = Regex.named_captures(~r/^(?<pid>\d+)$/m, output)
  address_match = Regex.named_captures(~r/^(?<address>unix:(path|abstract).*)$/m, output)
  pid = pid_match["pid"]
  address = address_match["address"]

  cond do
    pid && address -> {:ok, %{bus_pid: pid, bus_address: address}}
    address -> :pid_not_found
    true -> :error

and interact with it like this

  env: [
    {"DBUS_SESSION_BUS_ADDRESS", bus_address},
    {"DBUS_SESSION_BUS_PID", bus_pid}

This is excellent. Thank you so much!

@tj0 thanks for the tips about understanding which dbus interface to target.

1 Like

BTW, regarding the comment from @cblavier , it looks like that they are starting their own dbus session on Nerves and then interacting with dbus-send. I think this is probably because they bring the system up from scratch.

If you are planning to run on Ubuntu for example, you can just use the already existing
DBUS_SESSION_BUS_ADDRESS in your environment.

Anyway, I’m not really sure what you’re trying to build, so just remember that if the session/user dbus environmental variable already exists, that is the one you probably want.


I think I should be able to rely on DBUS_SESSION_BUS_ADDRESS existing, but it doesn’t look like DBUS_SESSION_BUS_PID exists. I’m guessing they set that env var with the pid of the spawned process (system pid not BEAM pid).

1 Like

This is going to be a dumb question, but I’ve not interacted with DBus directly before so please bear with me. How are you getting the destination and object name parameters for dbus-send?

I don’t know the dbus protocol in details, but I guess that destination and object names are messaging conventions you need to establish between the process sending/receiving messages.

For my purpose, I used the destinations and parameters that omxplayer is expecting. The best documentation I found was this script: omxplayer/ at master · popcornmix/omxplayer · GitHub

Yes, all the names are pretty random. I used emacs dbus interface to query and figure out what is happening on dbus. Also, a copious use of dbus-monitor to understand what events are being published.

For cli, I’ve used busctl:

$ busctl --user
NAME                                       PID PROCESS         USER    CONNECTION    UNIT SESSION DESCRIPTION
org.a11y.Bus                              1764 at-spi-bus-laun tj :1.9          -    -       -          
org.flatpak.Authenticator.Oci                - -               -       (activatable) -    -       -          
org.freedesktop.DBus                      1269 dbus-daemon     tj -             -    -       -          
org.freedesktop.Flatpak                   2433 flatpak-session tj :1.17         -    -       -          
org.freedesktop.Notifications             1822 dunst           tj :1.14         -    -       -     1718 nm-applet       tj :1.10         c2   -       -          
org.freedesktop.portal.Flatpak               - -               -       (activatable) -    -       -          
org.gnome.keyring.PrivatePrompter            - -               -       (activatable) -    -       -          
org.gnome.keyring.SystemPrompter             - -               -       (activatable) -    -       -          
org.gtk.GLib.PACRunner                       - -               -       (activatable) -    -       -          
org.mozilla.firefox.ZGVmYXVsdC1yZWxlYXNl 17451 xdg-dbus-proxy  tj :1.820        c2   -       -          
org.mpris.MediaPlayer2.mpv                5750 mpv             tj :1.968        -    -       -          
org.mpris.MediaPlayer2.playerctld         1749 playerctld      tj :1.7          -    -       -          

Also, check out linux - A list of available D-Bus services - Unix & Linux Stack Exchange

There’s a few examples in python there also for interaction. Also qdbus and qdbusviewer as QT-based dbus tools. I’ve never used any of them as I couldn’t figure out the correct packages for my distro.


nice tips, thanks. Have you figured out how/where to define your interfaces and services? On Arch it looks like the systemwide installation occurs in /usr/share/dbus-1/ but I’m not sure where to define user-specific definitions that wouldn’t require root privileges. This question has been shockingly hard to find answers for on google.

Yah, that is very true regarding dbus. :cry:

I have not made a program that publishes events, but this seems to be per-program from what I’ve seen when I was debugging the interface.

The only reference I could find which supports this is at IntroductionToDBus

Plan to update this thread with a more thorough breakdown when I wrap up the project but I just wanted to mention that in order to get the functionality out of dbus that I really wanted I had to break down and use Rustler to wrap dbus-rs bindings. The interaction can then be handled with busctl from scripts or from within the app using the dbus-rs calls. I’m sure there are other ways but this is the only workable solution I could find.

To anyone interested, I wanted to use the zbus crate instead of dbus-rs because the documentation on that crate is so good, but zbus is async first, so much that even the blocking API requires use of async. Async functions with Rustler were a layer of complexity beyond my current capacity.


I haven’t touched Rust in several months but if memory serves there are two ways:

  1. Use a global convenience function:
async fn do_async_stuff() -> usize {
  return 7;

fn main() {
  let future = do_async_stuff();
  1. If you have access to the Tokio runtime (which you absolutely can get by not using the #[tokio::main] macro and just put the 3-4 lines of boilerplate code in yourself, see here for info: main in tokio - Rust – I have copied the runtime initialization code from there) then you can just use it like this:
async fn do_async_stuff() -> usize {
  return 7;

fn main() {
  let mut rt = tokio::runtime::Builder::new_multi_thread()

  let future = do_async_stuff();

Rust async allows you to introduce those crossing points between async and sync code.

Thanks. The issue was around implementing Encoder trait or something like that. Not really the async logic itself. I just want sure how to implement for a Future.

Well if you send more info I can try my hand at it.