[SSSD] [PATCH] MONITOR: Correctly detect lack of response from services
Dmitri Pal
dpal at redhat.com
Wed Sep 14 17:33:40 UTC 2011
On 09/14/2011 01:22 PM, Stephen Gallagher wrote:
> We were incorrectly using DBUS_ERROR_TIMEOUT here. The correct
> behaviour is to check for DBUS_ERROR_NO_REPLY. This way we will
> properly handle the three-tries in the tasks_check_handler().
>
> D-BUS is rather confusing with these error codes.
> DBUS_ERROR_NO_REPLY: No reply to a message expecting one, usually means
> a timeout occurred.
>
> DBUS_ERROR_TIMEOUT: Certain timeout errors, possibly ETIMEDOUT on a
> socket.
>
> And just for added confusion, there's also:
> DBUS_ERROR_TIMED_OUT: Certain timeout errors, e.g. while starting a
> service.
>
> DBUS_ERROR_NO_REPLY is the only correct one for our usage. This explains
> the intermittent bug we were seeing where the monitor lost communication
> with its services (usually the data providers). Because of this loss of
> communication, the monitor was unable to notify the providers of changes
> to the routing table or resolv.conf, leading to being stuck offline
> until SSSD was restarted.
Is it safe to use strcmp in this case? Though the string is returned by
the library in case of a bug and bad string being returned we would crash.
Also does the call to get the string always guarantee a not NULL result?
> This is probably the root cause of
> https://bugzilla.redhat.com/show_bug.cgi?id=728343
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110914/6b3003a5/attachment.html>
More information about the sssd-devel
mailing list