On Fri, 2011-06-17 at 14:46 +0200, Jakub Hrozek wrote:
On 06/17/2011 01:59 PM, Stephen Gallagher wrote:
> We've put this off for far too long, but I think we need to decide on a
> formal specification of what the various log levels mean in SSSD (and
> then open a ticket to go through them all clean them up).
>
> We didn't do this in the past because we had expected that this would be
> handled when we eventually integrated with the ELAPI (Event-Logging API)
> project. Unfortunately, that project stalled upstream and its future is
> unknown.
>
> So I think we need to document the exact purpose of each log level and
> publish this information so that consumers of the SSSD can have a good
> understanding of what level they should set (or leave running in
> production).
>
> I'll give my first suggestions, and then I'll listen to criticism :)
>
>
> First, I think we need to break the debug levels up into three ranges,
> roughly corresponding to error messages, informational messages and
> developer messages.
>
> So I propose that error messages should be 0-3
> 0: Fatal failures. Anything that would prevent SSSD from starting up or
> causes it to cease running. (Example: sssd.conf fails to parse)
> 1: Critical failures. An error that doesn't kill the SSSD, but one that
> indicates that at least one major feature is not going to work properly
> (Example: Kerberos keytab does not have a valid principal for
> SASL/GSSAPI LDAP)
Should we always log these ^^^ to syslog or decide per-case?
I think all level-0 failures should log to LOG_FATAL, level-1 to
LOG_ERROR. We might consider rolling this into the DEBUG() macro itself
(rather than requiring double calls in the consumer code)
> 2: Serious failures. An error announcing that a particular request or
> operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
> 3. Minor failures. These are the errors that would percolate down to
> cause the operation failure of 2. (Example: The above PAM_SYSTEM_ERR was
> due to the krb5_child returning an unexpected error)
>
Ack
> Informational messages should be 4-6
> 4. Configuration settings (E.g. the dp_option loading)
> 5. Function data (E.g. LDAP search request data, Dynamic DNS message)
> 6. Tracing messages for functions (Example: received DBUS method call
> "ping")
>
I agree with DBus calls like reloadConfig or resetOffline being about
this level, but I think "pings" might be one level up.
That would move 7 to 8 and fill the ??? as well :-)
That's a good idea, but I'm not sure I agree with the split. Maybe:
6. Trace messages for operation functions (e.g. getAccountInfo,
pamHandler)
7. Trace messages for internal control functions (e.g. ping,
resetOffline)
> Developer messages should be 7-9
> 7. Contents of function-internal variables that may be interesting
> 8. ???
> 9. Extremely low-level tracing information (Example: adding/removing
> D-BUS watches)
>
Can/should we change the level existing debug messages? Something
related that I always wanted to do was move everything that is NOT
tracing information away from log level 9.
The reason being that we often use level 9 for more useful info that
gets mixed up with D-Bus watches, LDB tevent traces etc.
As I said in the first paragraph, once we decide on this official
ruling, I want to open a ticket to convert all existing DEBUG messages
(yeah, someone's going to be doing drudge work for a few days)