[389-users] largish member changes causing problems

[Rich Megginson]

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