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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel