You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default dbus timeout between the client-server application operating on system-bus is around 25 seconds.
I am trying to configure this to say 40s using the following parameter in the dbus-configuration file :
<limit name="reply_timeout">40000</limit>
However, this did not work. The client disconnected after 25s, with an error: Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
The next try I did was manually setting timeout at the server application, but that did not help too. std::unique_ptr<sdbus::IConnection> m_connection; m_connection->setMethodCallTimeout(40000);
Has anyone tried configuring a timeout and were successful?
Update:
I was able to resolve the issue at client application timeout, with the member withTimeout() when using convenience API.
eg. std::unique_ptr<sdbus::IProxy> m_Proxy; m_Proxy->callMethodAsync(...).withTimeout(40000000).onInterface(..).uponReplyInvoke(..)
The client application no longer throws the Timeout error after 25s. However, when I monitor the messages using dbus-monitor, I do not see any messages for the response. I expect a response message after 40s, to be seen on the DBus, but there is none. The request is seen however. The code inside uponReplyInvoke is also executed, which means there was a response provided by the server application.
I do not understand as to why there is no response on the dbus-monitor.
@vk-gst I've never used the limit element in the dbus config file, so I can't tell you from my experience. Setting the timeout on the connection should work. But it's meant to be called on the client side, not server side. All outgoing method calls through that connection should then have that timeout. Another, more granular, way is the one you've used -- defining the timeout for a specific call. As to why you don't see any response messages in dbus-monitor, I can't tell. It looks like out of scope of sdbus-c++. You may try to write a minimal example on the sd-bus (libsystemd) level and, if that occurs there with timeout > 25 secs, ask the question in systemd mailing list...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The default dbus timeout between the client-server application operating on system-bus is around 25 seconds.
I am trying to configure this to say 40s using the following parameter in the dbus-configuration file :
<limit name="reply_timeout">40000</limit>
However, this did not work. The client disconnected after 25s, with an error:
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
The next try I did was manually setting timeout at the server application, but that did not help too.
std::unique_ptr<sdbus::IConnection> m_connection;
m_connection->setMethodCallTimeout(40000);
Has anyone tried configuring a timeout and were successful?
Update:
I was able to resolve the issue at client application timeout, with the member
withTimeout()
when using convenience API.eg.
std::unique_ptr<sdbus::IProxy> m_Proxy;
m_Proxy->callMethodAsync(...).withTimeout(40000000).onInterface(..).uponReplyInvoke(..)
The client application no longer throws the Timeout error after 25s. However, when I monitor the messages using
dbus-monitor
, I do not see any messages for the response. I expect a response message after 40s, to be seen on the DBus, but there is none. The request is seen however. The code insideuponReplyInvoke
is also executed, which means there was a response provided by the server application.I do not understand as to why there is no response on the dbus-monitor.
Beta Was this translation helpful? Give feedback.
All reactions