On 03/27/2012 07:35 PM, Michael R. Gettes wrote:
output is below. I am starting to believe how my systems are administered is getting in the way.
How so?
So I don't spend too much time bothering you - is there some place I can find (or can you point me) to what programs should have run to massage the DBs so I might get back in biz and then I am going to have a bit of a chat with my sysadmins regarding our admin practices. I hate bothering you with this stuff. Or, if i simply remove 389 and re-install 1.2.9.9 will I be back in biz? these are not critical systems (test environment), but I need to get things working again so I can have a chat with my admins (show them how things break). Have I mentioned how grateful I am for your help?
[root@ldap-master-t02 slapd-cmu]# dbscan -f /var/lib/dirsrv/slapd-cmu/db/userRoot/entryrdn.db4 | head
100000:guid=00000000-0000-1000-24ae-0800207f02e6
ID: 100000; RDN: "guid=00000000-0000-1000-24AE-0800207F02E6"; NRDN: "guid=00000000-0000-1000-24ae-0800207f02e6"
100001:guid=7ff2dbbc-7623-11d7-8000-080020cc75d3
ID: 100001; RDN: "guid=7FF2DBBC-7623-11D7-8000-080020CC75D3"; NRDN: "guid=7ff2dbbc-7623-11d7-8000-080020cc75d3"
100002:guid=f79ff0d0-6416-11d5-8000-000080020af0
ID: 100002; RDN: "guid=F79FF0D0-6416-11D5-8000-000080020AF0"; NRDN: "guid=f79ff0d0-6416-11d5-8000-000080020af0"
100003:guid=00000000-0000-1000-3571-0800207f02e6
ID: 100003; RDN: "guid=00000000-0000-1000-3571-0800207F02E6"; NRDN: "guid=00000000-0000-1000-3571-0800207f02e6"
100004:guid=00000000-0000-1000-6366-0800207f02e6
ID: 100004; RDN: "guid=00000000-0000-1000-6366-0800207F02E6"; NRDN: "guid=00000000-0000-1000-6366-0800207f02e6"
[root@ldap-master-t02 slapd-cmu]# dbscan -f /var/lib/dirsrv/slapd-cmu/db/userRoot/entryrdn.db4 | tail
P99999:guid=329e90ce-494b-11d5-8000-080020cc75d3
ID: 21; RDN: "ou=person"; NRDN: "ou=person"
P9999:uid=jw6a
ID: 36; RDN: "ou=account"; NRDN: "ou=account"
P999:uid=toohey
ID: 36; RDN: "ou=account"; NRDN: "ou=account"
P99:ou=art
ID: 63; RDN: "o=CFA - COLLEGE OF FINE ARTS"; NRDN: "o=cfa - college of fine arts"
dc=cmu,dc=edu
ID: 1; RDN: "dc=cmu,dc=edu"; NRDN: "dc=cmu,dc=edu"
Ok. The problem was that the entryrdn index was not upgraded. Here's
what to do:
service dirsrv stop
/usr/lib64/dirsrv/slapd-cmu/db2index -n userRoot -t entryrdn
/usr/lib64/dirsrv/slapd-cmu/db2index -n NetscapeRoot -t entryrdn
service dirsrv start
On Mar 27, 2012, at 21:25, Rich Megginson wrote:
On 03/27/2012 07:14 PM, Michael R. Gettes wrote:
earlier in the log (sorry, i didn't look there) I see
[27/Mar/2012:20:19:50 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 256511, procpages: 55220
[27/Mar/2012:20:19:50 -0400] - WARNING: After allocating import cache 410416KB, the available memory is 615628KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import.
[27/Mar/2012:20:19:50 -0400] - Import allocates 410416KB import cache.
[27/Mar/2012:20:19:50 -0400] Upgrade DN Format - changelog: Start upgrade dn format.
[27/Mar/2012:20:19:50 -0400] Upgrade DN Format - Instance changelog in /var/lib/dirsrv/slapd-cmu/db/changelog is up-to-date
[27/Mar/2012:20:19:50 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 256511, procpages: 55220
[27/Mar/2012:20:19:50 -0400] - WARNING: After allocating import cache 410416KB, the available memory is 615628KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import.
[27/Mar/2012:20:19:50 -0400] - Import allocates 410416KB import cache.
[27/Mar/2012:20:19:50 -0400] Upgrade DN Format - NetscapeRoot: Start upgrade dn format.
[27/Mar/2012:20:19:50 -0400] Upgrade DN Format - Instance NetscapeRoot in /var/lib/dirsrv/slapd-cmu/db/NetscapeRoot is up-to-date
[27/Mar/2012:20:19:50 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 256511, procpages: 55219[27/Mar/2012:20:19:50 -0400] - WARNING: After allocating import cache 410416KB, the available memory is 615628KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import.
[27/Mar/2012:20:19:50 -0400] - Import allocates 410416KB import cache. [27/Mar/2012:20:19:50 -0400] Upgrade DN Format - userRoot: Start upgrade dn format.
[27/Mar/2012:20:19:50 -0400] Upgrade DN Format - Instance userRoot in /var/lib/dirsrv/slapd-cmu/db/userRoot is up-to-date
and
find /var/lib/dirsrv -name DBVERSION -exec cat {} \;
bdb/4.3/libreplication-plugin
bdb/4.3/libback-ldbm/newidl/rdn-format-2/dn-4514
bdb/4.3/libback-ldbm/newidl/rdn-format-2/dn-4514
bdb/4.3/libback-ldbm/newidl/rdn-format-2/dn-4514
bdb/4.3/libback-ldbm/newidl/rdn-format-2/dn-4514
yes, i did upgrade from 1.2.9.9
hmm - looks like the entryrdn conversion was missed - try this:
dbscan -f
/var/lib/dirsrv/slapd-cmu/db/userRoot/entryrdn.db4 | head
and
/var/lib/dirsrv/slapd-cmu/db/userRoot/entryrdn.db4 | tail
/mrg
On Mar 27, 2012, at 21:05, Rich Megginson wrote:
On 03/27/2012 06:58 PM, Michael R. Gettes wrote:
I have upgraded one of my masters to 1.2.10.3 and i see the following
[27/Mar/2012:20:25:04 -0400] - 389-Directory/1.2.10.3 B2012.065.2248 starting up
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - libdb: DB handle previously used in transaction, missing transaction handle
[27/Mar/2012:20:25:04 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests
[27/Mar/2012:20:25:04 -0400] - Listening on All Interfaces port 636 for LDAPS requests
[27/Mar/2012:20:30:04 -0400] NSMMReplicationPlugin - changelog program - cl5DBData2Entry: invalid data version
[27/Mar/2012:20:30:04 -0400] NSMMReplicationPlugin - changelog program - cl5DBData2Entry: invalid data version
is this serious?
I had to do an offline 'setup-ds-admin.pl -u' because i have everything as SSL and the online update doesn't seem to handle this case very well (i offer this info as i have no idea if it is relevant to the problem).
What should have happened is that during yum/rpm upgrade of the 389-ds-base package, it should have upgraded the database to the latest version. Did you upgrade from 1.2.9.9?
find /var/lib/dirsrv -name DBVERSION -exec cat {} \;
before
[27/Mar/2012:20:25:04 -0400] - 389-Directory/1.2.10.3 B2012.065.2248 starting up
you should have some messages about the database being upgraded
the only error in the setup was
[12/03/27:20:20:09] - [Setup] Warning Error: command 'getsebool httpd_can_connect_ldap' failed - output [getsebool: SELinux is disabled] error []
If you are really running with SELinux disabled, then this is just telling you that it couldn't perform some SELinux function because it is disabled, which is ok.
389-admin.x86_64 1.1.28-1.el5 installed
389-admin-console.noarch 1.1.8-1.el5 installed
389-admin-console-doc.noarch 1.1.8-1.el5 installed
389-adminutil.x86_64 1.1.15-1.el5 installed
389-console.noarch 1.1.7-3.el5 installed
389-ds.noarch 1.2.1-1.el5 installed
389-ds-base.x86_64 1.2.10.3-1.el5 installed
389-ds-base-libs.x86_64 1.2.10.3-1.el5 installed
389-ds-console.noarch 1.2.6-1.el5 installed
389-ds-console-doc.noarch 1.2.6-1.el5 installed
389-dsgw.x86_64 1.1.9-1.el5 installed
advice appreciated.
/mrg
On Mar 27, 2012, at 10:03, Rich Megginson wrote:
On 03/27/2012 08:01 AM, Michael R. Gettes wrote:
I just checked and only 1.2.10.3-1.el5 is in the epel-testing repo
1.2.10.3 should be fine as long as you don't use compare operations on virtual attributes.
I just pushed 1.2.10.4 to epel-testing - it should show up in the mirrors in a couple of days.
/mrg
On Mar 27, 2012, at 9:50, Michael R. Gettes wrote:
I judge from your questions this is not a known problem.
/mrg
On Mar 27, 2012, at 9:17, Rich Megginson wrote:
On 03/26/2012 08:25 PM, Michael R. Gettes wrote:
I am a little perplexed.
I am making a change to a groupOfNames object having some 16069 member attributes. I am deleting nearly 16000 members and then adding nearly 16000 members. CPU goes to 100% and never comes down. I have plenty of memory allocated (700MB) to nss-slapd and I have made the adjustments to allow for large objects (maxbersize). I end up having to kill -9 slapd. the annoying thing is some times it works, some times it doesn't. I can't seem to find any common conditions of the failures (or successes).
Are you using replication? If so, do you see the high CPU usage on the master or on the replica?
Are you able to reproduce with 389-ds-base-1.2.10.4-1 in epel-testing?
ds = 1.2.9.9
RHEL = 5.7
Thoughts?
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
