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 {{{
}}}
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}, }}}
revision 0001-Ticket-47636-errorlog-level-16384-is-listed-as-0-in-.patch
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]:
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...
Fix regression 0001-Ticket-47636-Error-log-levels-not-displayed-correctl.patch
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
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/973
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.