Is there any API available to check whether ConfD server is up or not?

[aasok]

I’m facing a situation where ConfD server is not up sometimes. In such situations, if the function confd_notification_send is called, it will result in segmentation fault. So, to prevent segmentation fault from happening, I first need to check if ConfD server is up & only then call confd_notification_send.

So, is there any API available to check whether ConfD server is up or not?

[jaka]

Hi aasok,

cdb_wait_start, cdb_get_phase or even “pidof confd” from terminal should let you know if server is running or not.
BR

[per]

@aasok

I’m facing a situation where ConfD server is not up sometimes. In such situations, if the function confd_notification_send is called, it will result in segmentation fault.

I don’t think so - testing it in the netconf_notifications example, it seems it just returns CONFD_EOF, as could be expected. Perhaps your application code doesn’t handle that return value correctly, causing the crash?

There is a “minor” issue due to the semantics of TCP connections, though - at least for “small” notifications, the first call of confd_notification_send() after the connection has been lost will actually succeed, and only the second call will result in CONFD_EOF (still no crash).

This issue can be avoided by doing what the example code does, i.e. include the daemon control socket in the poll() set. That way you get an immediate notification already when the connection is lost, and can take appropriate action. (I had to comment-out the handling of control-socket-ready-for-reading in order to do the test above.)

[per]

@per

I don’t think so - testing it in the netconf_notifications example, it seems it just returns CONFD_EOF, as could be expected.

Actually, there is a possibility, not quite matching your description, but perhaps related: the call is likely to result in a segmentation fault if you pass an invalid value for the struct confd_notification_ctx *nctx parameter. So why would it be invalid? Besides the (hopefully unlikely) case that your code has corrupted it by writing to it, all notification contexts will be released if you call confd_release_daemon(), which to quote the documentation will return “all memory that has been allocated by confd_init_daemon() and other functions for the daemon context” - the latter includes the notification contexts returned by confd_register_notification_stream().

@per

This issue can be avoided by doing what the example code does, i.e. include the daemon control socket in the poll() set. That way you get an immediate notification already when the connection is lost, and can take appropriate action.

Could it be the case that you already have such code, that closes the control and worker sockets, calls confd_release_daemon(), and perhaps even creates a new daemon context and connects control and worker sockets anew - but neglects to call confd_register_notification_stream() to create new notification context(s)?