On 11/23/2015 02:53 PM, Lukas Slebodnik wrote:
On (23/11/15 14:37), Pavel Reichl wrote:
>
>
> On 11/23/2015 10:26 AM, Lukas Slebodnik wrote:
> [snip]
>>>
>>> (And this is different than the 80-chars limit which still makes sense
>>> for developers who often like to vertically split their editors)
>>>
>> It's not about 80 character limit. We already does not meet this criteria.
>> Small example:
>> (Mon Nov 23 10:12:24 2015) [sssd[be[ipa.corp.example.com]]] [server_setup]
(0x0400): CONFDB: /var/lib/sss/db/config.ldb
>>
>> Even the 190 columns is not enough for sme messages.
>> (Mon Nov 23 10:12:24 2015) [sssd[be[ipa.corp.example.com]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getDomains on path /org/freedesktop/sssd/dataprovider
>>
>>
>> But with string representations it will be extra 20 columns.
>
> Yes, let's drop the number completely.
>>
>>>>
>>>>>>> c) the size of logs will be increased.
>>>>>>> "
>>>>>>>
>>>>>>> So... if INFO, ERROR, FATAL and so on are wrong, well. Is
there any idea how
>>>>>>> to improve readability of logs?
>>>>>>>
>>>>>> Not the simple one.
>>>>>>
>>>>>> Firstly we need to fix point a) ; otherwise we will just confuse
users with
>>>>>> any string representation of debug level.
>>>>>
>>>>> I think it would be enough to make sure that during the most common
>>>>> operations, there are no logs with failure levels. The difference
>>>>> between FUNC_DATA and TRACE_FUNC is small even to us, much less to
an
>>>>> admin.
>>>> So it might make sense to set clear difference between FUNC_DATA and
TRACE_FUNC
>>>> (or other debug_levels) and check it as part of review.
>>>>
>>>> Otherwise it does not make a sense to use such variety of debug levels.
>>>> Because if difference is small to us (developers) then we can merge them
>>>> and simplify things.
>>>
>>> Maybe, but neither of this helps admins distinguish what messages to
>>> look for in the logs.
>>
>> String representation of debug_level will not help either.
>
> I don't agree. For random user the difference between 0x0010 and 0x4000 is
> virtually non existing.
But they can use old numbers. Which are mentioned in sssd.conf (1..9).
The higher number means more verbose output. It still
does not solve the problems with maping new debug levels to the semantic
of that debug level. It can only be used just for increasing/decreasing
a verbosity of log files.
> But on contrary every code contributor is aware of
> significant difference between fatal failure or trace all or previously
> between 1 and 10. I support conversion of hexa numbers to strings as a mean
> for easier debugging by users.
>
One more time, The string representation will not help becuase @see point a)
It will just confuse users. So it's better to not confuse users and rather
print hexadecimal number which does not say anything. (but can be efficiently
used for filtering)
It seems that you are only one to think so.
>
> e.g. filter the most critical messages for big log file.
> grep -nE "\(0x00[1-8]0\)" sssd_domain.log
>
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
>