If you’re using a multi-container setup, you have to specifically specify which container(s) will get access to the DBUS socket via labels in the docker-compose.yml file, see: https://docs.resin.io/learn/develop/multicontainer/#labels
Had the same response from Python so tried in bash but also getting:
RUN apt-get update \
&& apt-get install -yq ccache wireless-tools dbus
RUN export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
RUN DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket \
dbus-send \
--system \
--print-reply \
--reply-timeout=2000 \
--type=method_call \
--dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.DBus.Properties.GetAll \
string:"org.freedesktop.NetworkManager"
Failed to open connection to "system" message bus: Failed to connect to socket /host/run/dbus/system_bus_socket: No such file or directory
You are using the dbus-send command inside the Dockerfile. Instead of invoking it during build time, you need to do that in runtime from your start.sh script.
@r4space, I believe I understand @majorz 's answer, although I don’t have much experience with dbus. It’s about the difference between the Dockerfile “instructions” RUN, CMD or ENTRYPOINT. The RUN instruction executes something that should modify the filesystem as a step to produce a docker image. Each RUN command results in a “layer” for the final image, and this is what majorz referred to as “build time”. The CMD and ENTRYPOINT instructions, on the other hand, specify something to be executed when your app container is started, which majorz called “runtime”.
Quoting balena’s Dockerfile documentation page:
CMD - This command will be run when the container starts up on your device, whereas RUN commands will be executed on our build servers. In a balena application, this is typically used to execute a start script or entrypoint for the users application. CMD should always be the last command in your Dockerfile. The only processes that will run inside the container are the CMD command and all processes that it spawns.
Init System - Whatever you define as CMD in your Dockerfile will be PID 1 of the process tree in your container. It also means that this PID 1 process needs to know how to properly process UNIX signals, reap orphan zombie processes and if it crashes, your whole container crashes, meaning you lose logs and debug info.
So instead of these two lines:
RUN export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
RUN ... dbus-send ...
Try placing the commands inside a shell script (could also be a Python script) (which majorz called “start.sh”) and running that script with the CMD instruction, something like:
Note that whatever you execute with CMD (like my_dbus_test.sh) should be a “long-lived” process if you are planning to upload it through balena’s platform (git push or balena push). If it’s a script that runs and quits straight away, then if I recall correctly the supervisor will keep restarting the container in an endless loop and you won’t be able to see / interact with it. (You can tell I’ve learned the hard way…)
Hello @mowi22 .
The error is Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
The bus address seems incorrect.
Do you have an ENV DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket line in your Dockerfile?
Ah, thanks, no, I’ve just added that to the dockerfile, but I’m still getting Failed to connect to the bus: /usr/bin/dbus-launch terminated abnormally without any error message
$ DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket \
dbus-send \
--system \
--print-reply \
--reply-timeout=2000 \
--type=method_call \
--dest=org.freedesktop.timedate1 \
/org/freedesktop/timedate1 \
org.freedesktop.DBus.Properties.GetAll \
string:"org.freedesktop.timedate1"
Failed to open connection to "system" message bus: Failed to connect to socket /host/run/dbus/system_bus_socket: No such file or directory
I am not using a multi-container setup, however by adding the io.balena.features.dbus label to my container I was able to get dbus-x11 and dbus to work inside my Ubuntu 18 container.
