Steps to reproduce:
[1] Setup a DS instance [2] Configure the objectclass index for userRoot
dn: cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: objectclass nsSystemIndex: true nsIndexIDListScanLimit: limit=-1 type=eq values=person nsIndexType: eq
[3] Import 100k user LDIF [4] Perform an ldapsearch using objectclass=person
ldapsearch -D "cn=directory manager" -w password -b "dc=example,dc=com" -xLLL objectclass=person dn
[5] Access log reports search as unindexed (notes=A)
You don't have to import a 100k ldif - just set the default idlistscanlimit to something really low, so that a search of e.g. (objectclass=top) will hit the limit and be unindexed.
I stop the server, edit dse.ldif, and restart. There seems to be some sort of corruption happening to the inst->inst_attrs avl tree, when the server calls ldbm_instance_create_default_indexes() to add the default indexes to the instance. Before that function is called at startup, inst->inst_attrs looks ok. But sometime during that call, the nodes in the tree start to show some sort of corruption:
(gdb) p (struct attrinfo )inst->inst_attrs->avl_right->avl_right $94 = {ai_type = 0x989780 "p\221\230", ai_indexmask = 1935764481, ai_index_rules = 0x989540, ai_dblayer = 0x989860, ai_dblayer_count = 9933184, ai_idl = 0x21, ai_attrcrypt = 0x6e6f6870656c6574, ai_key_cmp_fn = 0x7265626d754e65, ai_dup_cmp_fn = 0x97bf80, ai_substr_lens = 0x21, ai_sattr = { a_type = 0x6e6f6870656c6574 <error: Cannot access memory at address 0x6e6f6870656c6574>, a_present_values = {num = 1836404325, max = 7497058,
e.g. ai_type should be a string like "objectClass".
The root node looks ok, as well as its immediate children, this may explain why/how the acceptance tests are able to pass.
The problem is here: {{{ int ldbm_instance_index_config_enable_index(ldbm_instance inst, Slapi_Entry e) { char *index_name; int rc;
rc=ldbm_index_parse_entry(inst, e, "from DSE add", &index_name);
}}} The call to ldbm_index_parse_entry will actually replace the existing index, with the new one from e. This is bad.
Looks like the fix is that ldbm_instance_index_config_enable_index should not call ldbm_index_parse_entry but should just get the index using ainfo_get. The index should already exist. If not, then it should call ldbm_index_parse_entry to add it.
The problem is that, when the server restarts, and you have customized an index, and the customized index is also a default index (e.g. objectclass, sn, many more), when the server tries to add and enable any missing indexes, it will overwrite the existing config with the config from the default, wiping out any customizations made.
0001-Ticket-47831-server-restart-wipes-out-index-config-i.patch 0001-Ticket-47831-server-restart-wipes-out-index-config-i.patch
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1113605
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1113606
fc67fb8..4bccd2b 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 4bccd2b Author: Rich Megginson rmeggins@redhat.com Date: Wed Jun 25 16:49:50 2014 -0600 f86e1a2..e260d9f 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit e260d9fd9e680579677007b6466f4e9ad3323eb6 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jun 25 16:49:50 2014 -0600 e6762cb..18bc3e8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 18bc3e82c3919867f14747343e452019630b60d0 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jun 25 16:49:50 2014 -0600 2bae66a..111e11a 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 111e11a Author: Rich Megginson rmeggins@redhat.com Date: Wed Jun 25 16:49:50 2014 -0600 b3aae6b..5c5c960 master -> master commit 5c5c960 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jun 25 16:49:50 2014 -0600
This needs to go into 1.2.11 branch and all later branches
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: N/A
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/1162
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.