On Mon, Jul 13, 2015 at 09:34:23AM +0200, Lukas Slebodnik wrote:
On (01/07/15 12:48), Jakub Hrozek wrote:
>On Wed, Jul 01, 2015 at 12:03:48PM +0200, Pavel Březina wrote:
>> On 06/29/2015 06:13 PM, 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
>>
>> I think the best way to start is to look at the existing debug messages and
>> take advantage of the bit-mask based log levels - it's been there for a
>> while and there is lots of space to increase its granularity but we still
>> use it as 1-9 levels. That beeing said, we should create more levels so we
>> can really distinguish between important trace parts (event start, event
>> end), information (object not found but this was expected), low level stuff
>> (ldb traces that brings lots of noice to the highest level), etc.
>
>The ldb traces are a really good point.
>
>OK, I like the suggestion with newer debug levels, but we should be
>careful with not adding too many.
>
>The other thing to be careful about is that admins are used to just set:
> debug_level=10
We needn't extend old debug levels just bit mask version
and old debug level(0-9) can be a bitmask of more new debug_levels.
So if someone set debug_level 9 or 10 it will still enable all debug messages.
OK, that's a good idea.