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

[Anthony Messina]

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.

-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/20140929/7156c0fa/attachment.sig>