libelektra: dbus and rename plugin do not work together

There is a problem when the dbus and rename plugins are used at the same time. The dbus plugin seems not be aware of the renamed keys and notifies everyone with the raw key name. Furthermore it looks like the change detection does not work either.

$ kdb mount `pwd`/mkwrapper.ini system/machinekit/cnc ini type dbus rename tolower=0
$ kdb set system/machinekit/cnc/display/display test2

$ dbus-monitor --system type='signal',interface='org.libelektra',path='/org/libelektra/configuration'
ignal sender=org.freedesktop.DBus -> dest=:1.544 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.544"
signal sender=:1.545 -> dest=(null destination) serial=2 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0"
signal sender=:1.545 -> dest=(null destination) serial=3 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/BACKLASH"
signal sender=:1.545 -> dest=(null destination) serial=4 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/FERROR"
signal sender=:1.545 -> dest=(null destination) serial=5 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME"
signal sender=:1.545 -> dest=(null destination) serial=6 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_FINAL_VEL"
signal sender=:1.545 -> dest=(null destination) serial=7 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_IGNORE_LIMITS"
signal sender=:1.545 -> dest=(null destination) serial=8 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_IS_SHARED"
signal sender=:1.545 -> dest=(null destination) serial=9 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_LATCH_VEL"
signal sender=:1.545 -> dest=(null destination) serial=10 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_OFFSET"
signal sender=:1.545 -> dest=(null destination) serial=11 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyChanged
   string "system/machinekit/cnc/AXIS_0/HOME_SEARCH_VEL"
....

mkwrapper.ini is here: https://github.com/strahlex/mkwrapper-sim/blob/param/mkwrapper.ini

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 20 (16 by maintainers)

Commits related to this issue

do not change sync state for #404 — committed to ElektraInitiative/libelektra by deleted user 8 years ago
clear sync bits after! POSTCOMMIT otherwise logging + notifications plugins would not have sync information anymore for #404 when global plugins are used — committed to ElektraInitiative/libelektra by deleted user 8 years ago

Most upvoted comments

@markus2330 there is actually a completely different new decision also in here: How should notification plugins deal with renamed keys?. If dbus uses the renamed keys, this breaks dbusrecv plugin as it will not find the keys with their renamed names in the KDB if get and set transformation are different!

atmaxinger on Oct 28, 2022

To expand why the change tracking of the dbus plugin does not work correctly in this case: The dbus plugin does not do a value-based change tracking, but instead uses keyNeedsSync to find out whether a key has been flagged as changed.

The way the rename plugin works, is that it deletes the old key and creates a new key with the renamed name. This causes keyNeedsSync to be true for every renamed key.

This is why the dbus plugin wrongly comes to the conclusion that the key changed. (And another reason WHY we need unified change tracking in Elektra, as proposed in #4554)

atmaxinger on Oct 28, 2022