[SSSD] RFC: Improving the debug messages

Lukas Slebodnik lslebodn at redhat.com
Tue Jun 30 21:28:39 UTC 2015


On (29/06/15 18:13), 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]
                                                                 ^^^^^^^^^^
                                            The last part is single variable
                                            filter. I don't think we need to
                                            split it
>    [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.
This one is doable short term.

>- same for authentication
the same as above

>- 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.
the same as above

>- 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.
>
This one is not doable in short term.
Please consider AD provider and error causedb by "replacing" groups
after tokengroups. But I agree that in long term we shoudl do it.


>- anything that causes SSSD to fail to start should also emit a syslog
>  message. Admins don't really know about sssd debug logs.
We just need to enable logging to journald by default
+ change debug level. But it requires to fix previous point.

>- our man pages are not structured well, especially the LDAP man page is
>  too big and contains too many options.
Do you have an idea how to split man pages?

We do not have one long man page.
       sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
       sssd-ipa(5), sssd-ad(5), sssd-sudo(5),sss_cache(8), sss_debuglevel(8),
       sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8),
       sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8),
       sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8),
       sss_ssh_knownhostsproxy(8),sssd-ifp(5),pam_sss(8).  sss_rpcidmapd(5)

The main problem is that people needn't know about them
and/or they needn't know where to start.

>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.
The best way how to get familiar with sssd is to fix few bugs
in different part of sssd :-)

LS



More information about the sssd-devel mailing list