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
/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@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
