#49227 ldapsearch for nsslapd-errorlog-level returns incorrect values
Closed: wontfix 6 years ago Opened 7 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1441790

Description of problem:
nsslapd-errorlog-level shows weird numbers that doesn't look like error log
levels that can be found in documentation.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.6.1-6.el7.x86_64

How reproducible:
always

Steps to Reproduce:
$ ldapmodify -x -D "cn=Directory Manager" -w Secret123
dn: cn=config
changetype: modify
add: nsslapd-errorlog-level
nsslapd-errorlog-level: 8192

$ ldapsearch -o ldif-wrap=no -x -LLL -D 'cn=Directory Manager' -w Secret123 -b
'cn=config' '(nsslapd-errorlog-level=*)' nsslapd-errorlog-level

Actual results:
dn: cn=config
nsslapd-errorlog-level: 266346496


Expected results:
dn: cn=config
nsslapd-errorlog-level: 8192


Additional info:
In dse.ldif I see correct value:
# grep nsslapd-errorlog-level /etc/dirsrv/slapd-rhel7ds/dse.ldif
nsslapd-errorlog-level: 8192

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1441790

7 years ago

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1441790

7 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

7 years ago

Metadata Update from @mreynolds:
- Custom field origin adjusted to QE
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to defect

7 years ago

Looks good to me.

One minor request. Since you added new macro SLAPD_DEFAULT_FE_ERRORLOG_LEVEL, do we want to use it here, too?

178 - cfg->errorloglevel = SLAPD_DEFAULT_ERRORLOG_LEVEL;
179 + cfg->errorloglevel = 16384;

Metadata Update from @nhosoi:
- Custom field reviewstatus adjusted to ack (was: review)

7 years ago

Thanks Noriko,

f6ec67e..9804f8a master -> master

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: ack)
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

7 years ago

@mreynolds #define SLAPD_DEFAULT_ERRORLOG_LEVEL 266354688

How is that value used? I don't quite get why it's such a large value ....

@mreynolds #define SLAPD_DEFAULT_ERRORLOG_LEVEL 266354688

How is that value used? I don't quite get why it's such a large value ....

This is used for the logging levels via bitmasks. See slapi_log_error() in log.c and proto_slap.h:

#define LDAP_DEBUG_TRACE      0x00000001  /*         1 */
#define LDAP_DEBUG_PACKETS    0x00000002  /*         2 */
#define LDAP_DEBUG_ARGS       0x00000004  /*         4 */
#define LDAP_DEBUG_CONNS      0x00000008  /*         8 */
#define LDAP_DEBUG_BER        0x00000010  /*        16 */
#define LDAP_DEBUG_FILTER     0x00000020  /*        32 */
#define LDAP_DEBUG_CONFIG     0x00000040  /*        64 */
#define LDAP_DEBUG_ACL        0x00000080  /*       128 */
#define LDAP_DEBUG_STATS      0x00000100  /*       256 */
#define LDAP_DEBUG_STATS2     0x00000200  /*       512 */
#define LDAP_DEBUG_SHELL      0x00000400  /*      1024 */
#define LDAP_DEBUG_PARSE      0x00000800  /*      2048 */
#define LDAP_DEBUG_HOUSE      0x00001000  /*      4096 */
#define LDAP_DEBUG_REPL       0x00002000  /*      8192 */
#define LDAP_DEBUG_ANY        0x00004000  /*     16384 */
#define LDAP_DEBUG_CACHE      0x00008000  /*     32768 */
#define LDAP_DEBUG_PLUGIN     0x00010000  /*     65536 */
#define LDAP_DEBUG_TIMING     0x00020000  /*    131072 */
#define LDAP_DEBUG_ACLSUMMARY 0x00040000  /*    262144 */
#define LDAP_DEBUG_BACKLDBM   0x00080000  /*    524288 */
#define LDAP_DEBUG_NUNCSTANS  0x00100000  /*   1048576 */
#define LDAP_DEBUG_EMERG      0x00200000  /*   2097152 */
#define LDAP_DEBUG_ALERT      0x00400000  /*   4194304 */
#define LDAP_DEBUG_CRIT       0x00800000  /*   8388608 */
#define LDAP_DEBUG_ERR        0x01000000  /*  16777216 */
#define LDAP_DEBUG_WARNING    0x02000000  /*  33554432 */
#define LDAP_DEBUG_NOTICE     0x04000000  /*  67108864 */
#define LDAP_DEBUG_INFO       0x08000000  /* 134217728 */
#define LDAP_DEBUG_DEBUG      0x10000000  /* 268435456 */
#define LDAP_DEBUG_ALL_LEVELS   0xFFFFFF

I forgot to mention... The issue here, and what the fix addresses, is the fact that we use two log levels: internal and external. The external level is what is set in the config, and what we should see when we search for that value. The internal level is the bitmask of the external level. The internal level is what does all the real work in the code.

config_set_errorlog_level() in libglobs.c

level |= SLAPD_DEFAULT_ERRORLOG_LEVEL;

AHhhh thanks for the explanation, it's much appreciated. Where is the external -> internal translation occuring?

Its happening in config_set_errorlog_level() and a global variable slapd_ldap_debug is set. Then in log.c, slapi_log_error(), is where it is checked.

Metadata Update from @mreynolds:
- Issue status updated to: Open (was: Closed)

6 years ago

set log level to 65536+16384+8192+128=90240, but ldapsearch returns 73856 (90240-16384). In dse.ldif there is a correct value. So default loglevel is always subtracted no matter what.

Another issue. After setting log level 64 or 1 in dse.ldif, I get this message in the errors logs:
[29/May/2017:15:19:09.972284013 +0200] - NOTICE - slapd_bootstrap_config - nsslapd-errorlog-level: ignoring 64 (since -d 266354688 was given on the command line), but parameter -d is not given on the command line.

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to ack (was: review)

6 years ago

Looks good, I'm all for removing weird little edgecases like this. Great find.

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0 (was: 1.3.6.0)

6 years ago

3cf8563 Ticket 49227 - ldapsearch does not return the expected Error log level

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field version adjusted to None
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

6 years ago

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

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2286

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.