--- Comment #16 from Shawn McKinney <smckinney(a)symas.com> ---
(In reply to Howard Chu from comment #15)
(In reply to Shawn McKinney from comment #14)
> Clarifications / Level Set (courtesy of Quanah)
No. Wrong. Stop with the nonsense.
Ha, exactly, stop the madness ;-P
But, seriously, this is indicative of the confusion that has already been
> OpenLDAP's C code has two different types of logging:
> 1. "DEBUG" messages, which confusingly, are what loglevel controls:
> # loglevel of ACL:
> aci.c: Debug( LDAP_DEBUG_ACL, "aciNormalizeRight: perms:attr need
> to be pairs in '%s'\n", action->bv_val );
> # loglevel of STATS:
> delete.c: Debug( LDAP_DEBUG_STATS, "%s DEL dn="%s"\n",
> # etc
The Debug() macro checks both debuglevel and loglevel and routes messages
accordingly. It is the only official mechanism for either debug or log
messages from slapd.
OK, good. Clarity has been achieved, and confirms my observations of loglevel,
> 2. The actual debug messages, that only (normally) go to stderr:
> slapmodify.c: fprintf( stderr, "%s: could not %s
> entry dn="%s" "
> or (avoiding commandline tools)
Calling fprintf(stderr) is only valid for cmdline tools. Not for slapd
> syncrepl.c: fprintf(stderr, "merge_state: %s si_syncCookie [%d]
> %d %s\n",
> syncrepl.c: fprintf(stderr, "merge_state: %s si_cookieState [%d]
> %d %s\n",
Instances of fprintf(stderr) in daemon code are anomalies.
and so should converted to use the macro, right? (Admittedly low priority)
> When the man page says "debug messages", it's talking about the
> printed to stderr.
It is talking about messages printed to stderr because of the debuglevel
setting. it is not talking about the anomalous fprintf(stderr) messages
scattered thru daemon code that don't belong there.
So, this means we now have two mechanisms that do the same thing. To prevent
(the terminology) confusion, the old mechanism, debuglevel, should be
But, that's besides the point (documentation), and also low priority.
You are receiving this mail because:
You are on the CC list for the issue.