[SSSD] Discussion of debug log levels

Simo Sorce simo at redhat.com
Fri Jun 17 14:45:15 UTC 2011


On Fri, 2011-06-17 at 10:20 -0400, Simo Sorce wrote:
> > 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)
> > 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)
> > 
> > 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")
> > 
> > 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)
> 
> Looks fine to me, but should we also discuss a separate Logging
> facility
> that spits only logs that are of interest for admins/auditors ?
> 
> I am thinking of the difference between access/errors logs in
> apache/dirsrv/etc ... 

Thinking a bit more, I think we may want to change to use a debugging
level scheme like dirsrv has.

Ie, turn the log-level from a simple integer to a bit field and
associate each log level with a bit.

The reason is that often times you may want to specific log at level 9
to show up but you are not in the least interested about all messages
between levels 4-8

In samba we also had a way to specify which facility we wanted to log
about but I think that is not necessary with sssd given we already have
log files and levels splitted by daemon.

So if we take a 32bit integer we have 32 possible levels we can use.
Level 0 bugs still should always be reported so it doesn't take any
level.

So basically I would take your list and have something like this:

#define SSSDBG_CRIT_FAILURE   0x00000001   /* level 1 */
#define SSSDBG_OP_FAILURE     0x00000002   /* level 2 */
#define SSSDBG_MINOR_FAILURE  0x00000004   /* level 3 */
#define SSSDBG_CONF_SETTINGS  0x00000008   /* level 4 */
#define SSSDBG_FUNC_DATA      0x00000010   /* level 5 */
#define SSSDBG_TRACE_FUNC     0x00000020   /* level 6 */
#define SSSDBG_TRACE_LIBS     0x00000040  /* level 7 */
#define SSSDBG_TRACE_INTERNAL 0x00000080  /* level 8 */
#define SSSDBG_TRACE_ALL      0x00000100  /* level 9 */


We can still use the integers in the DEBUG macro for the transition and
just convert them to the bitfield in the macro before comparing the
bitfield to the current allowed messages.
On the side we can add a new debug macro that takes the new definitions
and establish this new macro is to be used in any new code. This way we
can slowly transition without having to touch any more code than
strictly necessary on the first go.


What is IMPORTANT is that we clearly define these log levels in the man
page with copious examples of what "numbers" to put in the "debug level"
config option to get it right.

If we want to be backwards compatible with currently set levels in
config files I think we have 2 options.

1) shift all levels in the bitfield by 3 and amrk the lowest 3 bits
reserved. If any of them is set it means the debug level was of the old
type so we "translate" it to the right bits instead.

2) Introduce a new option for fine grained level selection named
something like "debug mask" and use "debug level" as a backwards
compatible short cut:
"debug level = 9"
  is translated to:
    "debug mask = 511"
  or
    "debug mask = 0x1FF"


Later on we may want to start defining LOG messages like
#define SSSLOG_AUTH 0x0001, etc.. but this can be done in a separate
step to avoid putting too much meat on the fire all at the same time.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list