[SSSD] Discussion of debug log levels (take 2)

Jan Zeleny jzeleny at redhat.com
Mon Jun 20 19:55:08 UTC 2011


Stephen Gallagher <sgallagh at redhat.com> wrote:
> Ok, I'm going to try to summarize the responses from Simo and Jakub,
> then hopefully we'll accept them and we can add this information to the
> coding and contribution guidelines. (I have intentionally broken the
> thread).
> 
> I agree with Simo that we should break this into a bitfield. I'm going
> to suggest that we consider a match of 0x000F to be an error, 0x00F0 to
> be informational and 0x0F00 to be developer. This adjusts Simo's numbers
> slightly, but it makes a little more room available at each level in
> case we want to add a new level in the middle.
> 
> I also think we should change the config file option name to "debug"
> rather than "debug_mask". I think it's more readable.

How would this mask look and work exactly?

> #define SSSDBG_FATAL_FAILURE  0x0000   /* level 0 */
>     Fatal failures. Anything that would prevent SSSD from starting up or
> causes it to cease running. (Example: sssd.conf fails to parse)
> 
> #define SSSDBG_CRIT_FAILURE   0x0001   /* level 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)
> 
> #define SSSDBG_OP_FAILURE     0x0002   /* level 2 */
> Serious failures. An error announcing that a particular request or
> operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
> 
> #define SSSDBG_MINOR_FAILURE  0x0004   /* level 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)
> 
> #define SSSDBG_CONF_SETTINGS  0x0010   /* level 4 */
> Configuration settings (E.g. the dp_option loading)
> 
> #define SSSDBG_FUNC_DATA      0x0020   /* level 5 */
> Function data (E.g. LDAP search request data, Dynamic DNS message)
> 
> #define SSSDBG_TRACE_FUNC     0x0040   /* level 6 */
> Trace messages for operation functions (e.g. getAccountInfo,
> pamHandler)
> 
> #define SSSDBG_TRACE_LIBS     0x0100  /* level 7 */
> Trace messages for internal control functions (e.g. ping,
> resetOffline)
> 
> #define SSSDBG_TRACE_INTERNAL 0x0200  /* level 8 */
> Contents of function-internal variables that may be interesting
> 
> #define SSSDBG_TRACE_ALL      0x0400  /* level 9 */
> Extremely low-level tracing information (Example: adding/removing
> D-BUS watches)
> 
> 
> 
> For backwards compatibility, we would map the existing debug_level
> values as below:
> 
> SSS_DEBUG0: SSSDBG_FATAL_FAILURE
> SSS_DEBUG1: SSS_DEBUG0 & SSSDBG_CRIT_FAILURE
> SSS_DEBUG2: SSS_DEBUG1 & SSSDBG_OP_FAILURE
> SSS_DEBUG3: SSS_DEBUG2 & SSSDBG_MINOR_FAILURE
> SSS_DEBUG4: SSS_DEBUG3 & SSSDBG_CONF_SETTINGS
> SSS_DEBUG5: SSS_DEBUG4 & SSSDBG_FUNC_DATA
> SSS_DEBUG6: SSS_DEBUG5 & SSSDBG_TRACE_FUNC
> SSS_DEBUG7: SSS_DEBUG6 & SSSDBG_TRACE_LIBS
> SSS_DEBUG8: SSS_DEBUG7 & SSSDBG_TRACE_INTERNAL
> SSS_DEBUG9: SSS_DEBUG8 & SSSDBG_TRACE_ALL
> 
> 
> If we agree on these definitions, I will write it up on the wiki and
> we'll put the following policy in place:
> 
> All new code MUST use the new DEBUG definitions. Existing code being
> modified SHOULD convert related DEBUG messages to the new macros. It is
> NOT required to mass-convert existing messages at this time, but patches
> are welcome :)

When we are discussing debug messages, I vaguely recall that debug level 0 
logged only to /var/log/secure and not to /var/log/sssd/*. Is this intended?

Jan



More information about the sssd-devel mailing list