Failed to receive signal from dbus-send (CLI)

[lctasca]

I am trying to receive a signal emitted by a bash script using dbus-send in an application using the sdbus-cpp library.

Starting with an introspect XML:

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
	<interface name="com.test.CanInterfaceFctTests">
		<signal name="TestDigitalInputs">
			<arg name="input_port" type="y"/>
			<arg name="result" type="b"/>
			<arg name="test_status" type="s"/>
		</signal>
	</interface>
</node>

I generated the proxy using the xml2cpp tool:

sdbus-c++-xml2cpp can_interface_fct_tests_dbus_client_proxy.xml --proxy=can_interface_fct_tests_dbus_client_proxy.h

And implemented the proxy:

Header:

#ifndef INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_CLIENT_H_
#define INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_CLIENT_H_

#include <sdbus-c++/sdbus-c++.h>

#include <string>

#include "sdbus_cpp_glue/can_interface_fct_tests_dbus_client_proxy.h"

class CanInterfaceFctTestsDBusClient
    : public sdbus::ProxyInterfaces<com::test::CanInterfaceFctTests_proxy>
{
  public:
   CanInterfaceFctTestsDBusClient();
   ~CanInterfaceFctTestsDBusClient();

  protected:
   void onTestDigitalInputs(const uint8_t& input_port, const bool& result,
                            const std::string& test_status) override;
};

#endif  // INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_CLIENT_H_

Source:

#include "can_interface_fct_tests/can_interface_fct_tests_dbus_client.h"

#include "constants/dbus_constants.h"
#include "log/log_boost.h"

CanInterfaceFctTestsDBusClient::CanInterfaceFctTestsDBusClient()
    : ProxyInterfaces<com::test::CanInterfaceFctTests_proxy>(
          sdbus::ServiceName("com.test.CanInterfaceFctTests"),
          sdbus::ObjectPath("/com/test/can_interface_fct_tests"))
{
   registerProxy();
}

CanInterfaceFctTestsDBusClient::~CanInterfaceFctTestsDBusClient() { unregisterProxy(); }

void CanInterfaceFctTestsDBusClient::onTestDigitalInputs(const uint8_t& input_port,
                                                         const bool& result,
                                                         const std::string& test_status)
{
   // TODO - testing
   LOG_INFO << (int)input_port << "/" << result << "/" << test_status;
}

But when I try to emit the signal via CLI with the client running, nothing is showing (suppose to log the values):

dbus-send --system --type=signal /com/test/can_interface_fct_tests com.test.CanInterfaceFctTests.TestDigitalInputs byte:0 boolean:false string:"Test"

My guess is something related to the CLI dbus-send application validation (because it does not have a DBus connection, so it may not be identified as the correct emitter of the signal).
If that is the case, any chance of relaxing these validations somehow to allow this communication?

I had tried with bustctl emit and gdbus emit with similar results.
It would be much appreciated any clues...

[sangelovic]

Hi,

First, I converted this to a discussion thread. It's better to start a discussion first, and if it turns out there is an issue in sdbus-c++ library, then a GitHub issue can be created.

Second, you've provided some pieces of code, which is great, but you missed the most important part -- how do you start and use CanInterfaceFctTestsDBusClient proxy. It may well be you've forgotten to start an event loop? Or you've connected your proxy to a session bus while the signal is emitted on the system bus?

Furthermore, do you see the signal in dbus-monitor?

[lctasca]

Hello!

Yes, I can see the dbus-send signal in dbus monitor:

dbus-monitor --system interface='com.test.CanInterfaceFctTests'

signal time=1520610202.498351 sender=:1.204 -> destination=(null destination) serial=2 path=/com/test/can_interface_fct_tests; interface=com.test.CanInterfaceFctTests; member=TestDigitalInputs
   byte 0
   boolean false
   string "Test"

Since CanInterfaceFctTestsDBusClient is a proxy, I only construct it in another class, nothing more. According to the documentation, proxies create a system connection if the connection is not provided in the constructor, so I guess there is no need to start an inner loop. Am I wrong? If so, could you give an example of what I am missing? Also, could you reproduce my scenario on your side to see if I may have been missing something else?

One thing I forgot to mention is that I am using version 2.0 of the library...
Not sure if that changes something...

[sangelovic]

The documentation says the proxy will create a connection to the session when in a user context, and to the system bus otherwise .(it used to be system bus connection in the past, but latest with v2.0.0 this behavior has changed to mimic the behavior of underlying sd-bus library.) So please double-check that the proxy is not listening on a session bus while the signal is emitted on the system bus...

Otherwise I don't have much advice. I assume you create classic proxy (not light-weight proxy) -- this one spawns an internal event loop, so you should receive the signal. Also, the parameter types seem to match. Reproducing on my side is useless -- sdbus-c++ has a good test suite that verifies many scenarios, including signals. What you can do in addition is run sdbus-c++-unit-tests and sdbus-c++-integration-tests to see if they all pass... If they pass, then signals work, and the issue is somewhere on your side (like session/system bus mismatch).

Let me know.

[lctasca]

To investigate this issue further, I wrote a small adaptor using the same XML as the original post.

I generated the adaptor using the xml2cpp tool:

sdbus-c++-xml2cpp can_interface_fct_tests_dbus_server_adaptor.xml --adaptor=can_interface_fct_tests_dbus_server_adaptor.h

And implemented the adaptor:

Header:

#ifndef INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_SERVER_H_
#define INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_SERVER_H_

#include <sdbus-c++/sdbus-c++.h>

#include "sdbus_cpp_glue/can_interface_fct_tests_dbus_server_adaptor.h"

class CanInterfaceFctTestsDBusServer
    : public sdbus::AdaptorInterfaces<com::test::CanInterfaceFctTests_adaptor>
{
  public:
   CanInterfaceFctTestsDBusServer();
   ~CanInterfaceFctTestsDBusServer();

  protected:
};

#endif  // INC_CAN_INTERFACE_FCT_TESTS_CAN_INTERFACE_FCT_TESTS_DBUS_SERVER_H_

Source:

#include "can_interface/can_interface_dbus_server.h"

std::unique_ptr<sdbus::IConnection> sdbus_connection_ =
    sdbus::createSystemBusConnection(sdbus::ServiceName("com.test.CanInterfaceFctTests"));

CanInterfaceFctTestsDBusServer::CanInterfaceFctTestsDBusServer()
    : AdaptorInterfaces<com::test::CanInterfaceFctTests_adaptor>(
          *sdbus_connection_.get(), sdbus::ObjectPath("/com/test/can_interface_fct_tests"))
{
   registerAdaptor();
   sdbus_connection_->enterEventLoopAsync();

   emitTestDigitalInputs(0, false, "hi!");
}

CanInterfaceFctTestsDBusServer::~CanInterfaceFctTestsDBusServer()
{
   unregisterAdaptor();

   sdbus_connection_->leaveEventLoop();
}

And my dbus client successfully received the signal!

Which proves my client is working, but it still cannot receive the dbus-send call:

dbus-send --system --type=signal /com/test/can_interface_fct_tests com.test.CanInterfaceFctTests.TestDigitalInputs byte:0 boolean:false string:"Test"

As mentioned in the original post, I need to communicate a shell script to a C++ application. I know this is not common, but it needs to be done. I guess this is not covered on the library tests, right? Maybe tests are missing something...

I am still wondering if there is something related to the CLI dbus-send application validation at the sdbus-c++ side (because it does not have a DBus connection, so it may not be identified as the correct emitter of the signal).

Thanks in advance for any help...

[sangelovic]

@lctasca You are on the right track -- you need to provide a sender when emitting the signal with dbus-send, so the dbus-send connects to dbus-daemon in the name of that service:

dbus-send --system --type=signal --sender=com.test.CanInterfaceFctTests /com/test/can_interface_fct_tests com.test.CanInterfaceFctTests.TestDigitalInputs byte:0 boolean:false string:"Test"

The client, when registering to a signal, provides a filter condition that is based on sender, object path, interface name and signal name. Since you've specified the latter three, but no sender, the condition did not match the signal and thus the callback was not called.

Let me know if that helped.

[lctasca]

That does the trick!
The "--sender=" flag was missing since the beginning.
Thank you so much for your help @sangelovic!