On 05/16/2012 07:48 PM, Brad Schuetz wrote:
> On 05/16/2012 06:24 PM, Rich Megginson wrote:
>> On 05/16/2012 06:48 PM, Brad Schuetz wrote:
>>> Is there any way that I can remove the nsTombstone entries from the
>>> master server so I can get this under control? I think I found out
>>> why
>>> I have so many nsTombstone entries in the first place so I'd like
>>> to get
>>> the current ones deleted and see how much delete activity I'll have
>>> moving forward.
>>>
>>> I saw this bug report,
>>> <
https://bugzilla.redhat.com/show_bug.cgi?id=617862>, that seems to
>>> indicate that I should be able to ldapdelete the nsTombstone entries
>>> using their full dn, however it always says object not found.
>> Can you provide
>> 1) the exact ldapdelete command line
>> 2) the excerpts from the access and errors log from around the time of
>> the deletion
> Here's the command with only the username part of the DN redacted and
> the access log for the command, I confirmed that after the delete failed
> that the entry was in fact still there by running the ldap search again
> for nstombstone entries to be sure that it wasn't just a timing issue.
> Also attempted the same command with quotes around the DN to delete.
> The error log produced no entries around the time of the command
> being run.
>
> ldapdelete -x -D 'cn=Directory Manager' -W
>
nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=aeria005,ou=Users,ou=System,dc=cust,dc=omnis,dc=com
>
>
> This was the output from the above command:
>
> ldap_delete: No such object (32)
> matched DN:
> uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com
>
> access log:
> 17/May/2012:01:41:35 +0000] conn=947 fd=80 slot=80 SSL connection from
> ::1 to ::1
> [17/May/2012:01:41:35 +0000] conn=947 SSL 256-bit AES
> [17/May/2012:01:41:35 +0000] conn=947 op=0 BIND dn="cn=Directory
> Manager" method=128 version=3
> [17/May/2012:01:41:35 +0000] conn=947 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=directory manager"
> [17/May/2012:01:41:35 +0000] conn=947 op=1 DEL
>
dn="nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com"
>
> [17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
> nentries=0 etime=0
> [17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
> nentries=0 etime=0
> [17/May/2012:01:41:35 +0000] conn=947 op=2 UNBIND
> [17/May/2012:01:41:35 +0000] conn=947 op=2 fd=80 closed - U1
>
> However I can report that the internal process seems to have finally
> cleaned up the bulk of the entries, I had over 20k entries on the master
> and it's finally down to less than 100. I temporarily changed the
> values for when it should reap the entries to try and get it to clear
> them out internally after I fixed the issue that I believe was
> responsible for the extraneous deletes.
Good. I filed a ticket about the tombstone deletion issue:
https://fedorahosted.org/389/ticket/376
The fact that there are two result lines for the operation is a good
clue that something is going wrong.
Looks like my IO issue is resolved now that the tombstone entries aren't
going crazy.
Thanks for the help everyone.
--
Brad