Dbus: Failed to connect to socket /host/run/dbus/system


I am trying to check if the time was NTP synchronized.
I connect via resin CLI and then go into one of my containers.

root@a6e385b:~# balena exec -it 4aba7fde2842 bin//bash
root@raspberrypi3-a6e385b:/# 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

Any idea what went wrong?


Hi @zagatta-sonah!

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

Let us know if that helps!


And if I’m running a single container?

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 \

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.



I’m really just trying to get the python dbus api working but can’t get beyond invoking
import dbus
bus = dbus.SystemBus()

Get the same error about no such file

Was just trying bash as a pre-test



@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:

  • https://www.balena.io/docs/learn/develop/dockerfile/
  • 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:

COPY ./my_dbus_test.sh my_dbus_test.sh
CMD my_dbus_test.sh

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…) :slight_smile: