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.
2 Likes
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. 
2 Likes
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}
]
)
6 Likes
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.
3 Likes
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/dbuscontrol.sh 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 - - -
org.freedesktop.network-manager-applet 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.
2 Likes
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. 
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.
3 Likes
I haven’t touched Rust in several months but if memory serves there are two ways:
- Use a global convenience function:
async fn do_async_stuff() -> usize {
return 7;
}
fn main() {
let future = do_async_stuff();
futures::executor::block_on(future);
}
- 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()
.enable_all()
.build()
.unwrap();
let future = do_async_stuff();
rt.block_on(future);
}
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.
2 Likes
