[Date Prev][Date Next]
LDAP Debug messages & severity levels
slapd is often too silent when something fails.
One may need -d -1 or something to find out what is wrong -
and then useful messages can drown in others.
Also, if OpenLDAP is configured with --disable-debug, often
we get no error messages at all. That's plain wrong - fatal
error messages are not what one normally calls debugging.
I'd like to try again to introduce severity levels, this
time something simpler than the NEW_LOGGING experiment.
- Replace at least Debug() messages giving warnings and
errors, with macros that indicate severity level.
Info(), Error(), Warn(), etc.
configure --disable-debug would not disable the most severe
- Run-time configuration of which severity levels to log,
configured independently of the loglevel (which isn't really
a log "level", just a bit mask of different things to log).
Not sure how the loglevel and severity level should interact.
The most severe messages should be given independently of
loglevel, so maybe their macros do not need a loglevel.
With the others - log the message if both loglevel and
severity level is satisfied? That's inconsistent with severe
messages that are logged just due to severity level though.
Maybe it'll be easier to decide after the debug messages
have been classified by severity.
- Maybe the "loglevel" should be renamed (retaining the old
name for backwards compatibility), to avoid confusion with
the severity level which really is a "level".
- I think 4-5 severity levels should be enough: debug, (info),
warning, error, (fatal).
Could fold Info into Debug or Fatal into Error. I haven't
looked at just what Debug() is used for at the moment.
Statslog() would have level Info if Statslog is included in
this scheme at all, I don't know what else fits level Info.
include/ldap_log.h #defines twelve LDAP_LEVEL_* constants,
but they only seem to be used in the unused debug2syslog().
- The severity levels would be mapped to different syslog
levels, if syslog is enabled.
If anything more complicated is needed, we can worry about
that later rather than introducing something too complex and
later abandoning it, like NEW_LOGGING.