[SSSD] RFC: Improving the debug messages
Simo Sorce
simo at redhat.com
Mon Jun 29 21:53:45 UTC 2015
On Mon, 2015-06-29 at 18:13 +0200, Jakub Hrozek wrote:
> Hi,
>
> I spent many hours debugging SSSD in different scenarios last week and I
> admit it wasn't always easy -- and I have the source code knowledge I
> can use. I imagine it's considerably harder for users and admins..
>
> So this is a brainstorm request on how can we make debugging with SSSD
> easier. Maybe there are some low-hanging fruits that can be fixed
> easily. Off the top of my head:
>
> - it should be easier to see start and end of a request in the back end.
> Instead of:
> [be_get_account_info] (0x0200): Got request for [0x1001][1][name=admin]
> [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success)
> We could make the debug messages more explicit:
> [be_get_account_info] (0x0200): Received request for [object=user][key=name][value=admin]
> [acctinfo_callback] (0x0200): Finished request for [object=user][key=name][value=admin]. Returned 0,0,Success
>
> Then we could document the messages in our troubleshooting document.
> Please note I'm not proposing to turn debug messages into any kind of
> API and keep them the same forever, but decorate the usual flow with
> messages that make sense without source level knowledge.
>
> - same for authentication
>
> - same for responder cache requests. We seem to have gotten better with
> the new cache_req code there, so this is mostly about using the new
> code in all responders. But also the commands we receive from sockets
> should be printed in human-readable form.
>
> - Running sssd in environment where all actions complete successfully
> should emit no debug messages. Default log level should be moved to
> SSSDBG_OP_FAILURE or CRIT_FAILURE. (This basically amounts to checking
> all OP, FATAL and CRIT failure messages..)
>
> The reason is that sometimes sssd fails, but because logging is
> totally silent, we don't know what happened at all. Currently we have
> a couple of small bugs where we might print a loud DEBUG message just
> because we search for an entry which is not there etc.
>
> - anything that causes SSSD to fail to start should also emit a syslog
> message. Admins don't really know about sssd debug logs.
>
> - our man pages are not structured well, especially the LDAP man page is
> too big and contains too many options.
>
> One reason I'm bringing this up now is that we'll have a new SSSD developer
> starting soon and these might be nice tasks to start with AND they're
> also needed.
+1
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the sssd-devel
mailing list