9:25 p.m.
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).
ds = 1.2.9.9
RHEL = 5.7
Thoughts?
/mrg
8:17 a.m.
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?
/mrg
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
8:50 a.m.
I am using replication (2 masters, 3 consumers, fully replicated among them). High CPU
usage only on the master being modified. It happens on either master when the operation
is performed on it. The MOD being made never actually completes - I have to kill -9 the
server - so it never makes it to the other master or consumers by replication. I should
also note the changes I am making are in a single modify. I figured you would ask about
1.2.10 - I have not yet gotten there - but I will try to make it happen this week.
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?
>
> /mrg
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
8:58 a.m.
On 03/27/2012 07:50 AM, Michael R. Gettes wrote:
I am using replication (2 masters, 3 consumers, fully replicated
among them). High CPU usage only on the master being modified. It happens on either
master when the operation is performed on it. The MOD being made never actually completes
- I have to kill -9 the server - so it never makes it to the other master or consumers by
replication. I should also note the changes I am making are in a single modify. I
figured you would ask about 1.2.10 - I have not yet gotten there - but I will try to make
it happen this week.
I judge from your questions this is not a known problem.
Dealing with large groups
is problematic, but not known to completely
clobber the server.
/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?
>>
>> /mrg
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
9:01 a.m.
I just checked and only 1.2.10.3-1.el5 is in the epel-testing repo
/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?
>
9:03 a.m.
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?
9:11 a.m.
Michael,
Something else to check is the Referential Integrity Plugin. Is it
enabled? If it is, something that I have seen that helps is to set the
interval from 0 to 1 second. Or turn it off to rule it out, but then of
course it won't do its job.
Regards,
Mark
On 03/26/2012 10: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).
ds = 1.2.9.9
RHEL = 5.7
Thoughts?
/mrg
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
11:28 a.m.
Ref int is not on.
On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol(a)redhat.com> wrote:
Michael,
Something else to check is the Referential Integrity Plugin. Is it
enabled? If it is, something that I have seen that helps is to set the
interval from 0 to 1 second. Or turn it off to rule it out, but then of
course it won't do its job.
Regards,
Mark
On 03/26/2012 10: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).
>
> ds = 1.2.9.9
> RHEL = 5.7
>
> Thoughts?
>
> /mrg
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.**org <389-users(a)lists.fedoraproject.org>
>
https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://a...
>
12:39 p.m.
It may also be the memberOf plugin, is the attribute memberOf
replicated in your configuration? I tested deleting/adding/replacing
in one shot a group of ~6000 entries with memberOf and referint
enabled. It took about 30 seconds to complete but it never hanged
(389DS v1.2.9.10).
2012/3/27 Michael Gettes <gettes(a)gmail.com>:
Ref int is not on.
On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol(a)redhat.com> wrote:
>
> Michael,
>
> Something else to check is the Referential Integrity Plugin. Â Is it
> enabled? Â If it is, something that I have seen that helps is to set the
> interval from 0 to 1 second. Â Or turn it off to rule it out, but then of
> course it won't do its job.
>
> Regards,
> Mark
>
> On 03/26/2012 10: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).
>>
>> ds = 1.2.9.9
>> RHEL = 5.7
>>
>> Thoughts?
>>
>> /mrg
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
12:54 p.m.
Nope, no memberof either.
On Mar 27, 2012 1:39 PM, "Andrey Ivanov" <andrey.ivanov(a)polytechnique.fr>
wrote:
It may also be the memberOf plugin, is the attribute memberOf
replicated in your configuration? I tested deleting/adding/replacing
in one shot a group of ~6000 entries with memberOf and referint
enabled. It took about 30 seconds to complete but it never hanged
(389DS v1.2.9.10).
2012/3/27 Michael Gettes <gettes(a)gmail.com>:
> Ref int is not on.
>
> On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol(a)redhat.com>
wrote:
>>
>> Michael,
>>
>> Something else to check is the Referential Integrity Plugin. Is it
>> enabled? If it is, something that I have seen that helps is to set the
>> interval from 0 to 1 second. Or turn it off to rule it out, but then of
>> course it won't do its job.
>>
>> Regards,
>> Mark
>>
>> On 03/26/2012 10: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).
>>>
>>> ds = 1.2.9.9
>>> RHEL = 5.7
>>>
>>> Thoughts?
>>>
>>> /mrg
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
7:58 p.m.
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).
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 []
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?
8:05 p.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
8:14 p.m.
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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
8:25 p.m.
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(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
8:35 p.m.
output is below. I am starting to believe how my systems are administered is getting in
the way. 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"
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(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
8:42 p.m.
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(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
4412
days inactive
4413
days old
389-users@lists.fedoraproject.org
15 comments
4 participants
participants (4)
-
Ivanov Andrey (M.) -
Mark Reynolds -
Michael Gettes -
Rich Megginson