-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BecomeMonitor with destination matching returns too many unrelated messages #232
Comments
Well, there's still a problem: I'm trying to use Could this be a bug in |
It installs 2 matches, one for I know, this is quite unfortunate. However, I am unaware of a solution for this. The dbus-specification defines this in a way that just either causes spurious message drops, or you just don't filter (as we do). |
I will close this, as this is the expected and documented behavior. Given the current specification, I am unaware of a solution for this unfortunate feature disparity. If anyone has more input on this, please let us know! |
Can you please point me to mentioned documentation? I have tried to find this in both busctl monitor man page or help and dbus-monitor man page, but neither mentions this issue. It seems to me expected. Issue #367 can be seen as duplicate, but also proof this is not seen as fixed. |
This behavior is specific to dbus-broker and documented as part of its deviations to the reference implementation: https:/bus1/dbus-broker/wiki/Deviations |
I am afraid documenting it at that location is well hidden from mere mortal wondering, why the filtering does not work. It has no indication in manual pages of tools using it. I tend to think broker should just refuse that filter and force those tools use not ignored destination filter, but omit it from the filter. What is the reason for accepting something being ignored? Are there specific applications, which set destination filter but would be difficult to modify to omit it? At least for those monitor tools that filter were given explicitly by the user, so ignoring it silently is not user intuitive. Especially for busctl, which does not have other filters possible. If it could emit just warning message as the first received message, it might work better. I don't understand DBus protocol enough to know possible fixes. I understand documenting it on monitor tools is tricky, because they can be used on previous dbus-daemon, where this limitation does not apply. So ideally it should be emitted from dbus-broker runtime. In current form it means |
I'm trying to monitor a specific service, but
dbus-broker
gives me lots of other unrelated messages:All of these have nothing to do with
org.kde.plasma.gmenu_dbusmenu_proxy
. They are neither coming from nor heading to the process holding that service name.From the wiki, I am aware that "we err on the side of delivering unexpected messages, rather than dropping expected ones" when destination matching is in use, but I'm not expecting such a low signal-to-noise ratio.
EDIT: Okay, apparently I somehow missed the previous sentence: "we treat any match specifying a destination filter as if the destination filter had not been there", so I guess this is expected.
The text was updated successfully, but these errors were encountered: