[389-users] largish member changes causing problems
Rich Megginson
rmeggins at redhat.com
Wed Mar 28 01:42:22 UTC 2012
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 at 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 at 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 at lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
More information about the 389-users
mailing list