[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