[SSSD] RFC: Improving the debug messages

Jan Pazdziora jpazdziora at redhat.com
Tue Jun 30 08:30:16 UTC 2015


On Mon, Jun 29, 2015 at 06:13:20PM +0200, Jakub Hrozek wrote:
> 
> 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.

Then the question is if the first part
([be_get_account_info]/[acctinfo_callback]) of those lines shouldn't
match, for easy search'n'jump to the "matching bracket". Something
like [account info >] ... and [account info <] would be even better,
distinguishing the entry points (ha, nice, so the call at least got
here) from the exits.

> - 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.

It'd be great if the default option was to emit one error message per
failure (per operation, where operation should be defined from user's
point of view, not developer's point of view) and no message for
success. The next level would be to have one error message per failure
and one message per success, so that it's easy to observe what is
going on without getting into too much detail.

> - anything that causes SSSD to fail to start should also emit a syslog
>   message. Admins don't really know about sssd debug logs.

We have a ticket https://fedorahosted.org/sssd/ticket/2687 filed for
this one.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat



More information about the sssd-devel mailing list