org.freedesktop.DBus.Error.FileNotFound errors in non-systemd environment about sdbus-cpp

[rnarasappa]

Hi Stanislav,

Thanks for responding. Last week I was on holidays.
The dbus-daemon doesn't use the option "--address=systemd:". Based on your hint to look at the value of DBUS_SYSTEM_BUS_ADDRESS, I checked and noticed that the path indeed required a correction, i.e., default dbus build configuration used localstatedir=/usr/var. But I had the value /var/run/dbus/system_bus_socket set in DBUS_SYSTEM_BUS_ADDRESS.

In addition, I noticed we also need to include the string "unix:path". That is,
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/usr/var/run/dbus/system_bus_socket

With this, the sdbus-c++ unit and integration tests are passing now.
Thanks for your help.

regards,
Raghunath

[sangelovic]

Hi Raghunath, I have never so far seen such errors in both systemd and non-systemd environments. Error messages look like the library could not open connection to dbus-daemon. Are you sure dbus-daemon is running in your system? If yes, are other D-Bus services you might have there working properly? If yes, can you try running the tests with root privileges? Best regards, Stanislav.

…

On Thu, May 16, 2019 at 8:29 AM rnarasappa ***@***.***> wrote: Hi, I am trying to use the sdbus-c++ 0.6.0 package on a non-systemd environment. That is, I have generated libsystemd.so.0.25.0 from systemd-241 as per instructions in https://github.com/Kistler-Group/sdbus-cpp/blob/master/docs/using-sdbus-c++.md#solving-libsystemd-dependency. These are built on an ARM cross compilation environment. While running the sdbus-c++-unit-tests, there are 27 failures (out of 68 tests) with the below error message for all of these failures: *"[org.freedesktop.DBus.Error.FileNotFound] Failed to get default system bus (No such file or directory)" thrown in the test body.* And, the same kind of error when sdbus-c++-integration-tests is run as below: *terminate called after throwing an instance of 'sdbus::Error' what(): [org.freedesktop.DBus.Error.FileNotFound] Failed to open bus (No such file or directory) Aborted* Full log is in the attached text file. sdbus_cpp_test_failures.txt <https://github.com/Kistler-Group/sdbus-cpp/files/3185650/sdbus_cpp_test_failures.txt> Has anybody got these tests working on a non-systemd environmennt.? Any idea if I am doing anything wrong w.r.t these tests.? Any help, is much appreciated. regards, Raghunath — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#53?email_source=notifications&email_token=ABM3OUUYRY4RW42HV2HBQMLPVT5LZA5CNFSM4HNJKZIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUCXZEA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABM3OUQQIN35KV3FBPF2EJTPVT5LZANCNFSM4HNJKZIA> .

[rnarasappa]

Hi Stanislav,

Yes, dbus-daemon is running. I have an example server & client code based on dbus-c++ library that works fine (they communicate over dbus) with the same dbus-daemon running.

The dbus-1.9.16 is being used and I have set the flag enable_systemd=no during its configuration (since I don't use a systemd environment). I believe that's correct.? Are there any other dbus configuration flags that need to be set for usage on a non-systemd environment with sdbus-c++ APIs.?

And, yes only the root login is being used for running all of these binaries & tests.

regards,
Raghunath

[sangelovic]

Sorry for a bit delayed reply, have been quite busy.

I don't know what enable_systemd=no does exactly, but I don't think that is the cause of your problem. With what arguments is the dbus-daemon running in your system? I think it should not run with "--address=systemd:" parameter.

It might also very well be that the D-Bus socket path in your system is different than what sd-bus (implementation under sdbus-c++) expects. sd-bus by default tries opening /run/dbus/system_bus_socket, unless DBUS_SYSTEM_BUS_ADDRESS environment variable is set (see e.g. balena-os/wifi-connect#72). D-Bus socket path for system bus is mentioned in in D-Bus configuration file /usr/share/dbus-1/system.conf, under <listen> node. Please check whether they match, and try setting DBUS_SYSTEM_BUS_ADDRESS before running sdbus-c++ tests if not, and let me know.

[lujfsd]

Hi Raghunath,
When you cross compile systemd, have you encountered the following error?
issue#12717
Can you give some advice?
Thanks!

[sangelovic]

Hey lujfsd, are you using Yocto for cross-compilation? If so, what version? From the error description it seems like you don't have necessary dependencies for building libsystemd in your recipe. Please make sure you have libcap as DEPENDS and RDEPENDS dependency, among others (other DEPENDS dependencies are e.g. meson-native ninja-native git-native gperf-native gettext-native util-linux glibc).

Btw. I've prepared recipe for sdbus-c++ for Yocto versions Sumo, Thud, Warrior, and current master. They will soon be PRed to OpenEmbedded repo, I'm just waiting for the upcoming sdbus-c++ release.

[lujfsd]

I'm not using Yocto 。I have solved this issues temporarily. issue#12717
Thanks for you reply。
I will be try if the Yocto released.

[rnarasappa]

Hi lujfsd,

Yes, I had seen the issue of linux/capability.h not being found during cross compilation for ARM.
I recall I had to just set the options right in my cross-file.txt. That is, the --sysroot, -DDESTDIR, -I options were passed with relevant staging & include paths. Both c_args/c_link_args and cpp_args/cpp_link_args were set to identical values for these options.

I didn't patch anything to the meson.build file. I had built systemd-241 with libcap 2.25.

regards,
Raghunath

[lujfsd]

Hi，Raghunath
thank you, could you upload your cross-file.txt, please?

[rnarasappa]

cross_file.txt
Hi lujfsd,
Attached my cross-file.txt
regards,
Raghunath