stevensonmt
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.
Marked As Solved
cblavier
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 = Port.open({:spawn, cmd}, [:binary])
receive do
{^port, {:data, output}} -> {:ok, port, output}
after
@start_timeout -> :error
end
end
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
end
end
and interact with it like this
System.cmd(
"dbus-send",
[
"--session",
"--print-reply=literal",
"--dest=#{dest}",
object_name,
action,
message
],
env: [
{"DBUS_SESSION_BUS_ADDRESS", bus_address},
{"DBUS_SESSION_BUS_PID", bus_pid}
]
)
Also Liked
stevensonmt
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.
tj0
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.
tj0
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. ![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








