On 05/16/2017 02:23 PM, Paul Whitney wrote:

Hi guys,

I am trying to update the index on our userRoot database. I imported the attribute using the ldif2db routine. Error log reports success.

Then I ran the db2index.pl routine with no particular attribute

(in essence I guess the whole database is re-indexed) causing the database to grow, fill partition up, and crash.

What files are consuming all the disk space?

Tested on another system similar process but this time used the "-t" option with the new attribute. Error log shows success. However, no re-indexing occurred.

How are you verifying the index was not re-indexed?
Are you using dbscan to verify that a key is missing that should be present?
Are you looking at file timestamps?
What is in the errors log exactly?

When we import through the console, then add the attribute for indexing, the console kicks off a reindex of the database with the new attribute selected.

Stats:

Version 389-DS: 1.3.5.10

Can you please do a: rpm -qa | grep 389-ds-base

Command used to import attribute:

/usr/lib64/dirsrv/slapd-test/ldif2db -n userRoot -i /var/log/dirsrv/slapd-test/my.ldif; systemctl start dirsrv@test.service

Command to index:

/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory Manager" -w - -n userRoot (re-indexes all but fills partition and crashes)

Second test:

/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory Manager" -w - -n userRoot -t my_attribute:pres (log reports success but does not re-index like it does on console.)

Any ideas on why through console it indexes the whole database with new attribute, but not from the command line?

To see what the console does verses db2index.pl you can always turn on audit logging, and you'll see what it is doing for each one.

Thanks,
Mark

Paul M. Whitney
E-mail: paul.whitney@mac.com
Sent from my browser.

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org