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(a)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(a)mac.com
Sent from my browser.
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org