#925 Create a new DEBUG() facility
Closed: Fixed None Opened 10 years ago by jhrozek.

This ticket is based on two threads on sssd-devel:



I'll sumarize the important bits here for the developer who would be implementing the feature. Please refer to the original threads for more context and complete discussion.

Right now, our DEBUG() logging macro takes a positive integer as the log level. The user provides an sssd log level at runtime or in config file. SSSD in turns executes ALL DEBUG() macros where the first parameter is less or equal than the debug level.

As Simo pointed out, this is not always desirable. 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.

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

The new DEBUG() facility should reserve the space below 0xF to provide backwards compatibility and translate the old integer-based codes into the new bitfield-based ones.

This was Stephen's proposal for the new macros (the only difference is that the values are shifted to accomodate the reserved space):

#define SSSDBG_FATAL_FAILURE  0x0010   /* 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   0x0020   /* 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

#define SSSDBG_OP_FAILURE     0x0040   /* 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  0x0080   /* 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  0x0100   /* level 4 */
Configuration settings (E.g. the dp_option loading)

#define SSSDBG_FUNC_DATA      0x0200   /* level 5 */
Function data (E.g. LDAP search request data, Dynamic DNS message)

#define SSSDBG_TRACE_FUNC     0x0400   /* level 6 */
Trace messages for operation functions (e.g. getAccountInfo,

#define SSSDBG_TRACE_LIBS     0x1000  /* level 7 */
Trace messages for internal control functions (e.g. ping,

#define SSSDBG_TRACE_INTERNAL 0x2000  /* level 8 */
Contents of function-internal variables that may be interesting

#define SSSDBG_TRACE_ALL      0x4000  /* level 9 */
Extremely low-level tracing information (Example: adding/removing
D-BUS watches)

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.

Tentatively assigning this enhancement to Pavel B. We will triage as usual on our weekly meeting.

type: defect => enhancement

Fields changed

owner: somebody => pbrezina

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

Fields changed

patch: 0 => 1
rhbz: =>

Fixed by:
- a32ae27
- 267bdd4
- 99dd40a
- 930b8d8
- fe60346
- 89caf5e

resolution: => fixed
status: new => closed

Fields changed

rhbz: => 0

Metadata Update from @jhrozek:
- Issue assigned to pbrezina
- Issue set to the milestone: SSSD 1.7.0

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1967

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.