[SSSD] Discussion of debug log levels

Jakub Hrozek jhrozek at redhat.com
Fri Jun 17 12:46:17 UTC 2011


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?

> 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 :-)

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110617/a787402c/attachment.sig>


More information about the sssd-devel mailing list