openldap-2.4.39 with lmdb backend running on centos 6.4. This occurred on one of the consumers and other consumers didnt have any issue. I was running args,stats and sync loglevel, and I see the following in the log. Each do_syncrep2 shows dnMatch.
The contextcsn got out of sync and I used slapd -c to resync it and it looks ok now.
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c [7a441664]
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c [eebf38e5]
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc0185aa630 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: syncrepl_entry: rid=703 be_modify cn=cname,ou=Group,dc=server,dc=com (0)
Aug 25 03:45:02 servernameslapd[16312]: slap_queue_csn: queing 0x7fc01859e320 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc01850f060 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: connection_get(12)
Aug 25 03:45:02 servernameslapd[16312]: do_syncrep2: rid=703 cookie=rid=703,sid=001,csn=20140825014502.428281Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: syncrepl_message_to_entry: rid=703 DN: cn=development,ou=somegroup,dc=server,dc=com, UUID: a06de85e-b545-102d-9482-cde2fff247a7
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3
Aug 25 03:45:02 servernameslapd[16312]: dnMatch 1
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -2 <snip>
Is throwing it out there, is it possible that because of args loglevel, it created some kind of race condition resulting in something like this? I had been running args on this host to gather some debug for a different issue. This server is not heavily loaded or used, how safe is it to run with args for a long period of time?
On Mon, Aug 25, 2014 at 4:30 PM, Daniel Jung mimianddaniel@gmail.com wrote:
openldap-2.4.39 with lmdb backend running on centos 6.4. This occurred on one of the consumers and other consumers didnt have any issue. I was running args,stats and sync loglevel, and I see the following in the log. Each do_syncrep2 shows dnMatch.
The contextcsn got out of sync and I used slapd -c to resync it and it looks ok now.
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c [7a441664]
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c [eebf38e5]
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc0185aa630 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: syncrepl_entry: rid=703 be_modify cn=cname,ou=Group,dc=server,dc=com (0)
Aug 25 03:45:02 servernameslapd[16312]: slap_queue_csn: queing 0x7fc01859e320 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com
Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN
Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text=""
Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc01850f060 20140825014502.251709Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: connection_get(12)
Aug 25 03:45:02 servernameslapd[16312]: do_syncrep2: rid=703 cookie=rid=703,sid=001,csn=20140825014502.428281Z#000000#001#000000
Aug 25 03:45:02 servernameslapd[16312]: syncrepl_message_to_entry: rid=703 DN: cn=development,ou=somegroup,dc=server,dc=com, UUID: a06de85e-b545-102d-9482-cde2fff247a7
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3
Aug 25 03:45:02 servernameslapd[16312]: dnMatch 1
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3
Aug 25 03:45:02 servernameslapd[16312]: dnMatch -2
<snip>
openldap-technical@openldap.org