Return Status of RPC


I am using ietf-system model rpc ,If the system is using NTP then this operation will fail with error-tag ‘operation-failed’ and error-app-tag value of ‘ntp-active’."

When I am doing : user-rpc --content run-system-datetime.xml from netopeer2-cli , I am getting OK but in logread status shows fail.

user-rpc --content run-system-datetime.xml OK

how do I get the error-tag at NETCONF?

From ietf-system.yang:

Re-read your question.
Perhaps you are looking for this config (see the confd.conf(5) man page):

/confdConfig/netconf/rpcErrors (close | inline) [close]
If rpcErrors is ‘inline’, and an error occurs during the processing of a or request when ConfD tries to fetch some data from a data provider, ConfD will generate an rpc-error element in the faulty element, and continue to process the next element.
If an error occurs and rpcErrors is ‘close’, the NETCONF transport is closed by ConfD.

yes, this clear the doubt. So in this case there is no way other than logread to know if the rpc is successful

As far as I know, the /confdConfig/netconf/rpcErrors setting that @cohult refers to only applies to the “builtin” <get> and <get-config> (probably <get-data> too) RPCs, where the data is delivered to the NETCONF agent “piece wise” from potentially multiple different data providers. The result of invoking a custom RPC or action such as set-current-datetime on the other hand is delivered as a single message from a single data provider to the NETCONF agent. In this case it is entirely up to the action() callback implementation to report any failures with the actual operation, such as the ntp-active error described in the spec.

So, since ConfD doesn’t formally include ietf-system.yang nor instrumentation for it (but does ship with a sample implementation in the examples.confd/linuxcfg example), the first question is what implementation you are using, and the second question is how that implementation attempts to report the ntp-active error. Also, you mentioned errors in logs (I think) - what errors are those?

Thanks @per, you are absolutely right.
The examples.confd/linuxcfg example will return the “ntp-active” error if that ietf-system.yang set-current-datetime RPC fails due to /system/ntp/enable being set to true.
An easy way to test run the examples.confd/linuxcfg example is to drop the ConfD installer, the examples tar-ball, and the libconfd tar-ball into the Docker based demo setup that can be found here :

I have reported the ntp-active error in the sysrepo callback, about the error in the log is the same ntp active error.

I’m sorry, but I’m afraid this means nothing to me.

What is “the sysrepo callback” - instrumentation code that you wrote? Please describe (as I wrote) how that code attempts to report the ntp-active error. Providing the actual relevant code is the best way to do that.

What does it mean that the log has “the same ntp active error”? Please provide the actual, complete text from the log.