[389-users] Proper handling of "No original_tombstone for changenumber" errors

[Anthony Messina]

On Tuesday, September 30, 2014 09:20:16 AM Ludwig Krispenz wrote:
> On 09/29/2014 11:15 PM, Anthony Messina wrote:
> > Thanks, Ludwig.  I will open a ticket.  Can you elaborate on whether or
> > not
> > this is a logging issue, or actually an issue with my
> > replication/changelog, etc.  As I said, I'm concerned about the flakiness
> > of 389 DS prior to the upgrade to FreeIPA 4.
> 
> This is just an additional message, which can become annoying, but it 
> does not influence the path of execution (no return code chenaged, 
> branch,..), so the effective behaviour should be as before.

Thanks for letting me know.  Have a good day.  -A

> > On Monday, September 29, 2014 02:24:08 PM Ludwig Krispenz wrote:
> >> Hi,
> >> 
> >> I think the message was introduced when tombstone handling was partly
> >> rewritten to fix some bugs and improve entry cache management.
> >> It is logged if a delete transaction has to be retried and no tombstone
> >> entry is found. In the normal case this should not happen, but looks
> >> like this is in the retro changelog during changelog trimming and for
> >> the changelog a delete does not create a tombstone.
> >> In my opinion there should be an additional check before logging this
> >> message.
> >> 
> >> Can you open a ticket ?
> >> 
> >> Thanks,
> >> Ludwig
> >> 
> >> On 09/29/2014 11:56 AM, Anthony Messina wrote:
> >>> Using two fully updated FreeIPA F20 masters with freeipa-
> >>> server-3.3.5-1.fc20.x86_64 and 389-ds-base-1.3.2.23-1.fc20.x86_64, I've
> >>> noticed that I'm getting a lot of the following errors in the 389 DS
> >>> error
> >>> log, especially at server startup.
> >>> 
> >>> "No original_tombstone for changenumber=511851,cn=changelog!!"
> >>> 
> >>> Most often, the same changenumber repeats over and over, but there are
> >>> some
> >>> other changenumbers listed as well.  The changenumbers are different on
> >>> each master.
> >>> 
> >>> My concern is I'm preparing my thought process about the upcoming
> >>> upgrade
> >>> from F20 to F21 and it looks like I may need to create a new FreeIPA
> >>> master and "migrate" the Dogtag stuff, etc. rather than a simple "yum
> >>> upgrade" on each master.  Yuck!
> >>> 
> >>> What is the proper way to correct for these apparent errors and get
> >>> these
> >>> masters working with each other in a clean manner?

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20141001/6e07414c/attachment.sig>