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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
