Warning about Udev and DBus
Moin, from time to time I see warnings like this Failed to connect to Udev serviceHelper daemon via D-Bus: org.freedesktop.DBus.Error.ServiceUnknown I can reproduce it in a VM with a fresh Debian testing and BIT from upstream master repo. Which package is might be missing here? This is the full terminal output user@Barclay ~/backintime/common (master)$ ./backintime Back In Time Version: 1.3.2 Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details. WARNING: Failed to connect to Udev serviceHelper daemon via D-Bus: org.freedesktop.DBus.Error.ServiceUnknown WARNING: D-Bus message: The name net.launchpad.backintime.serviceHelper was not provided by any .service files WARNING: Udev-based profiles cannot be changed or checked due to Udev serviceHelper connection failure
These warnings are cause by my bug fix for PR "BiT does not start with DBus exception NameHasNoOwner" and you can find the warning in common/tools.py starting Line 1896: https://github.com/bit-team/backintime/commit/ad4e91c1c9c3b85e30d77f418e8f2a... Before that change you could not even start BiT ;-) To solve it you have to install the "serviceHelper" of BiT which is either done via - installing the distro BiT qt package (because "serviceHelper" is contained in the GUI despite it is also used in the backend -> wrong layer from the software architecture point of view); this uses a released version auf "serviceHelper" even for the Github dev version so you cannot test changes in serviceHelper.py itself this way - manually installing the serviceHelper from your Github version via cd qt ./configure && make && make install My takeaway: - I should another warning line with a hint how to fix the warning (by installing the serviceHelper). Problem: The installation steps are different on each distro so a link to Github FAQs or README would be best but creates a soft dependency (never change the link target ;-) On Sun, 2022-10-23 at 07:27 +0000, c.buhtz@posteo.jp wrote:
Moin,
from time to time I see warnings like this
Failed to connect to Udev serviceHelper daemon via D-Bus: org.freedesktop.DBus.Error.ServiceUnknown
I can reproduce it in a VM with a fresh Debian testing and BIT from upstream master repo. Which package is might be missing here?
This is the full terminal output
user@Barclay ~/backintime/common (master)$ ./backintime
Back In Time Version: 1.3.2
Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details.
WARNING: Failed to connect to Udev serviceHelper daemon via D-Bus: org.freedesktop.DBus.Error.ServiceUnknown WARNING: D-Bus message: The name net.launchpad.backintime.serviceHelper was not provided by any .service files WARNING: Udev-based profiles cannot be changed or checked due to Udev serviceHelper connection failure _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: python@altfeld-im.de
Hello Jürgen, thanks for explaining. It cause a little problem in "test_backintime.py::TestBackInTime.test_local_snapshot_is_successful()" (https://github.com/bit-team/backintime/blob/4b09eba80237d64b84a3ed2c4aba1c44...) The output on stderr is explicit checked here if it fits to that lines INFO: Lock INFO: Take a new snapshot. Profile: 1 Main profile INFO: Call rsync to take the snapshot INFO: Save config file INFO: Save permissions INFO: Create info file INFO: Unlock But in my situation (testing machine without installed BIT but running BIT from git repo) it fails because there are also that WARNING messages in. It seems to me it is the only test that is affected. What do you think how to handle that? One approach would be to modify the test that way that it still checks for the existence of that INFO lines but ignore the other lines. What do you think? Kind Christian
Hi, On Sun, Oct 23, 2022 at 01:19:16PM +0000, c.buhtz@posteo.jp wrote:
One approach would be to modify the test that way that it still checks for the existence of that INFO lines but ignore the other lines. What do you think?
I think that kind of defeats the purpose of the test ;) We want to know if anything happens that isn't "the usual". But we might modify the test so that it specifically ignores the DBus warning, because that's out of scope for that test. Michael
Im already onto this issue (one of two reasons way building on Arch is failing ATM, see https://github.com/bit-team/backintime/issues/1333). I will send a PR until tonight I think. On Sun, 2022-10-23 at 13:19 +0000, c.buhtz@posteo.jp wrote:
Hello Jürgen,
thanks for explaining.
It cause a little problem in "test_backintime.py::TestBackInTime.test_local_snapshot_is_successful()" (https://github.com/bit-team/backintime/blob/4b09eba80237d64b84a3ed2c4aba1c44...)
The output on stderr is explicit checked here if it fits to that lines
INFO: Lock INFO: Take a new snapshot. Profile: 1 Main profile INFO: Call rsync to take the snapshot INFO: Save config file INFO: Save permissions INFO: Create info file INFO: Unlock
But in my situation (testing machine without installed BIT but running BIT from git repo) it fails because there are also that WARNING messages in.
It seems to me it is the only test that is affected. What do you think how to handle that?
One approach would be to modify the test that way that it still checks for the existence of that INFO lines but ignore the other lines. What do you think?
Kind Christian _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: python@altfeld-im.de
Dear Jürgen, On 2022-10-23 16:06 BiT dev <python@altfeld-im.de> wrote:
Im already onto this issue (one of two reasons way building on Arch is failing ATM, see https://github.com/bit-team/backintime/issues/1333).
But what can I do to manually (on my testing systems) do make this udev-debus-error-message go away?
On Sat, 2022-10-29 at 12:39 +0000, c.buhtz@posteo.jp wrote:
But what can I do to manually (on my testing systems) do make this udev-debus-error-message go away?
Could you please give me some context around your question so that I can give a more specific answer? Generally: - To get rid of DBus errors and warnings only a successful installation of BiT common does really help (after solving all problems to get that far ;-) -> make install - Fixing #1333 is still on my TODO list which says (internal comments): BiT fails to build from AUR with yay in Arch https://github.com/bit-team/backintime/issues/1333 -> yay -S backintime-cli-git backintime-git Reasons: 1. Missing dependencies on fresh install in PKGBUILD: sudo pacman -Sy python-packaging (by BiT) + sudo pacman -Sy python-pyfakefs (only for some unit tests) 2. Error in implementation of "--diagnostics": RTE when using new rsync version that supports -VV to write version information as JSON because BiT tries a string trim on a dict (created from JSON) in that case instead of trimming a version string in 3. Unit test bug that I have introduced by changing the log output (write all log to stderr, incl. INFO and WARNING) https://github.com/bit-team/backintime/pull/1337 One unit test now fails in case of a first-time installation because the BiT serviceHelper D-Bus daemon is not yet installed and BiT throws a different sequence of warnings than the unit test ist ignoring (the regexp ignores any output at the beginning and end of the log output, but not within the expected output) for line in error.split("\n") # returns a list of strings new_list = [line for line in error.split("\n") if line ...] new_list = [] .... new_list.append(line) if not (line.startswith('TextGenerator')): "\n".join(new_list) 4. Further unit test bug(s) that we introduced with "--diagnostics" in case of unexpected or missing results -> eg. non-standard language settings (LC_ALL=C)
Hi Jürgen On 2022-10-29 20:53 BiT dev <python@altfeld-im.de> wrote:
On Sat, 2022-10-29 at 12:39 +0000, c.buhtz@posteo.jp wrote:
But what can I do to manually (on my testing systems) do make this udev-debus-error-message go away?
Could you please give me some context around your question so that I can give a more specific answer?
I create a fresh virtual machine and clone the repo. Then I run BIT directly via "qt/backintime-qt --debug" from the repo. I don't do the make stuff. I thought it is easy to solve. But I didn't understand the background of the problem. So it is OK for me to wait for an official fix of it. I can live with the WARNING messages on terminal while doing my manual tests.
participants (3)
-
BiT dev -
c.buhtz＠posteo.jp -
Michael Büker