Skip to content
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.

Sign up for GitHub

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

Jump to bottom

DBus daemon and dbus-send tool #207

Closed
tory-kk opened this issue Jan 17, 2023 · 4 comments
Closed

DBus daemon and dbus-send tool #207

tory-kk opened this issue Jan 17, 2023 · 4 comments

Comments

@tory-kk
Copy link

tory-kk commented Jan 17, 2023

Hello,
Currently, we have a setup with Java DBus daemon, Java service that exports object, and Java client that sends messages to the exported object. And it works like a charm.

However, we recently noticed that dbus-send tool does not work properly - it doesn't receive a response from Java daemon.

An example:
We tried to send messages to the daemon via command-line and got the following response:

$ dbus-send --bus="tcp:host=localhost,port=36139,guid=fc8572521dcc41b9a927645066366912" --print-reply --reply-timeout=600000 --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:'test.service' string:'replace'

Error org.freedesktop.DBus.Error.Disconnected: Connection was disconnected before a reply was received

At the same time if the request is sent without asking for response the command-line succeeds:

$ dbus-send --bus="tcp:host=localhost,port=36139,guid=fc8572521dcc41b9a927645066366912" --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:'test.service' string:'replace' && echo "OK"

OK

If we send command to the system DBus, response from the requested service is received:

$ dbus-send --system --print-reply --reply-timeout=600000 --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.RestartUnit string:'puppet.service' string:'replace'

method return time=1673963470.955449 sender=:1.1 -> destination=:1.276 serial=5660 reply_serial=2
   object path "/org/freedesktop/systemd1/job/6596"

Is there some miss-configuration of the daemon on our side?
Are we doing something wrong or missing something? Please help us to solve the issue.

Attaching a gist with simple project with the daemon and exporter: link
@hypfvieh
Copy link
Owner

As far as I see right now, there seem to be multiple issues with this setup.
I'll investigate that further and report back later...

hypfvieh added a commit that referenced this issue Jan 20, 2023
@hypfvieh
Improvements of Message class
5152ee0 
This change includes several changes at once.

1) Use Object[] instead of a Map for the message header

The header was stored in a Map<Byte, Object>, where the byte key
defines the header field number in the actual message.

Using Map as container provided a nicer API but creates additional
overhead. Also the get() calls on a Map always uses hashCode() to find
the proper key.

Additionally, changes made to the header Map were never written back
to the message.

As the key is just a byte and the header of a DBus message only has 10
entries, an array of Object is the better option.
The array index defines the position in the message header. Index 0 is
omitted (invalid according to DBus Spec).
Looking up values using the array index is a lot faster.

2) Fix issues when running as daemon (Issue #207)

When the Java DBusDaemon was used and a second program exported methods to this
DBusDaemon, requesting results from these methods using dbus-send
failed.

This was due to the message header was corrupted when a message was
forwarded to the requester.

Updating the target for a message was done using setSource() method
which was (and still is) a very nasty beast.
First it clears the current buffers, then rewrites the initial part of
the message. After that, the header is rewritten (that part was wrong
since the beginning). After the header the body bytes are appendend.

The broken part did remove the 'signature' indicating byte for any
MethodReturn call.
@hypfvieh
Copy link
Owner

Alright... after a 2 days of investigation and trail & error I finally got it.

This setup has two major problems, one is a bug in dbus-java, the other is the usage of dbus-send.

First the bug:
When using dbus-java as DBusDaemon, messages which has to be forwarded from one application to another (app1 exports something app2 wants to call) failed due to broken message headers.

This was a really difficult to find and fix bug.
When the DBusDaemon receives the result of the call from app1 it changes the message header and sends the message to the requester (app2). The header is updated when setSource(String) is called on the message.
This code is pretty difficult to understand and it seems to be broken since the beginning of this project.
In that method, the message is cleared and re-filled after the header has been changed. The changed header was wrong and the resulting message was unreadable by dbus-send.

The second issue is your usage of dbus-send.
When using dbus-send with --address option, it does not do proper handshaking. It just sends the method call you want to run but omits sending the "Hello" message.
To get this to work, you have to set the DBUS_SESSION_BUS_ADDRESS environment variable.
Example:
DBUS_SESSION_BUS_ADDRESS="tcp:host=localhost,port=43540,guid=c6d8a3d70fdfcc80ce03510ee263acb8" dbus-send --print-reply --reply-timeout=600000 --type=method_call --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:'test.service' string:'replace'

@tory-kk
Copy link
Author

tory-kk commented Jan 24, 2023

Thank you very much! Everything works perfectly. :)
Are there any estimates about the release of a new version?

@hypfvieh
Copy link
Owner

Nope, no ETA for any release. Maybe in a few weeks somewhere in february/march depending on how much issues are arsing until then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hypfvieh @tory-kk