#47636 errorlog-level 16384 is listed as 0 in cn=config
Closed: Fixed None Opened 6 years ago by nkinder.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1012991

Description of problem:

Using ldapmodify to set errorlog-level to 16384 or:

nsslapd-errorlog-level: 16384

When I verify the updated setting using ldapsearch, I get a value of '0' in
return. But if I grep the dse.ldif file, then the expected value of 16384 is
returned. For other values, both an ldapsearch and a grep do actually return
the expected result.


Version-Release number of selected component (if applicable):

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)

# uname -p
x86_64

# rpm -qa | grep redhat-ds
redhat-ds-base-9.1.0-1.el6dsrv.x86_64
redhat-ds-9.1.0-1.el6.x86_64
redhat-ds-admin-9.1.0-1.el6.x86_64
redhat-ds-console-doc-9.1.0-1.el6.noarch
redhat-ds-console-9.1.0-1.el6.noarch

# rpm -qa | grep 389-ds
389-ds-base-1.2.11.15-20.el6_4.x86_64
389-ds-console-doc-1.2.7-1.el6.noarch
389-ds-console-1.2.7-1.el6.noarch
389-ds-base-libs-1.2.11.15-20.el6_4.x86_64


Steps to Reproduce:

[Test #1]
# ldapmodify -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level: 8192

modifying entry "cn=config"

^C

# ldapsearch -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
-b "cn=config" | grep -i errorlog-level
nsslapd-errorlog-level: 8192

# grep errorlog-level /etc/dirsrv/slapd-nss-ds-ca-2/dse.ldif
nsslapd-errorlog-level: 8192
[/Test #1]

[Test #2]
# ldapmodify -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level: 16384

modifying entry "cn=config"

^C

# ldapsearch -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
-b "cn=config" | grep -i errorlog-level
nsslapd-errorlog-level: 0

# grep errorlog-level /etc/dirsrv/slapd-nss-ds-ca-2/dse.ldif
nsslapd-errorlog-level: 16384
[/Test #2]

[Test #3]
# ldapmodify -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level: 32768

modifying entry "cn=config"

^C

# ldapsearch -x -y ~/.rootdnpass -h localhost -p 390 -D "cn=Directory Manager"
-b "cn=config" | grep -i errorlog-level
nsslapd-errorlog-level: 32768

# grep errorlog-level /etc/dirsrv/slapd-nss-ds-ca-2/dse.ldif
nsslapd-errorlog-level: 32768
[/Test #3]

This could have an impact on Disk Space Monitoring (daemon.c), as it might see the log level 16364 as verbose logging, when in fact it is not.

Rather defining the value as both a string and as an integer, you should have
{{{

define SLAPD_DEFAULT_ERRORLOG_LEVEL 16384

}}}

Then, whenever you need to use this value as a string, use the STRINGIFYDEFINE() macro. This macro will "cast" a macro "int" to a string.
{{{
const char *strval = STRINGIFYDEFINE(SLAPD_DEFAULT_ERRORLOG_LEVEL);
}}}

For example, see ldbm_config.c:
{{{
{CONFIG_DB_DEADLOCK_POLICY, CONFIG_TYPE_INT, STRINGIFYDEFINE(DB_LOCK_YOUNGEST), &ldbm_config_db_deadlock_policy_get, &ldbm_config_db_deadlock_policy_set, CONFIG_FLAG_ALWAYS_SHOW|CONFIG_FLAG_ALLOW_RUNNING_CHANGE},
}}}

Replying to [comment:6 rmeggins]:

Rather defining the value as both a string and as an integer, you should have
{{{

define SLAPD_DEFAULT_ERRORLOG_LEVEL 16384

}}}

Then, whenever you need to use this value as a string, use the STRINGIFYDEFINE() macro. This macro will "cast" a macro "int" to a string.
{{{
const char *strval = STRINGIFYDEFINE(SLAPD_DEFAULT_ERRORLOG_LEVEL);
}}}

For example, see ldbm_config.c:
{{{
{CONFIG_DB_DEADLOCK_POLICY, CONFIG_TYPE_INT, STRINGIFYDEFINE(DB_LOCK_YOUNGEST), &ldbm_config_db_deadlock_policy_get, &ldbm_config_db_deadlock_policy_set, CONFIG_FLAG_ALWAYS_SHOW|CONFIG_FLAG_ALLOW_RUNNING_CHANGE},
}}}

Yeah I never noticed that before. Okay, new patch attached.

Your new patch looks good to me. A question... When we start the server, we could add the error log level by adding "-d <error_log_level>". For instance, to enable the replication log level, the command line was "-d 8192". Does it change to 8192 + 16384? Or remains 8192?

Replying to [comment:8 nhosoi]:

Your new patch looks good to me. A question... When we start the server, we could add the error log level by adding "-d <error_log_level>". For instance, to enable the replication log level, the command line was "-d 8192". Does it change to 8192 + 16384? Or remains 8192?

It still works the same, 8192 is all you need. 16384 is always bitmasked out. Since 16384 is always assumed you only need to add together the "other" log levels.

Replying to [comment:9 mreynolds]:

Replying to [comment:8 nhosoi]:

Your new patch looks good to me. A question... When we start the server, we could add the error log level by adding "-d <error_log_level>". For instance, to enable the replication log level, the command line was "-d 8192". Does it change to 8192 + 16384? Or remains 8192?

It still works the same, 8192 is all you need. 16384 is always bitmasked out. Since 16384 is always assumed you only need to add together the "other" log levels.

Very nice. Thank you for the confirmation, Mark!

git merge ticket47636
Updating b22970e..933cbd5
Fast-forward
ldap/servers/slapd/daemon.c | 8 +++++---
ldap/servers/slapd/libglobs.c | 17 +++--------------
ldap/servers/slapd/slap.h | 1 +
3 files changed, 9 insertions(+), 17 deletions(-)

git push origin master
b22970e..933cbd5 master -> master

commit 933cbd5
Author: Mark Reynolds mreynolds@redhat.com
Date: Thu May 22 15:27:02 2014 -0400

There are other error log level inconsistencies between the dse.ldif and the searched cn=config entry. Reopening...

da90d57..f12e121 master -> master
commit f12e121
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Dec 8 15:50:53 2014 -0500

61d1211..7b32ab0 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 7b32ab0

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.3 backlog

3 years ago

Login to comment on this ticket.

Metadata