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?
Thanks. -A
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?
Thanks. -A
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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?
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.
-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?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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?
On Monday, September 29, 2014 02:24:08 PM Ludwig Krispenz wrote:
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 ?
https://fedorahosted.org/389/ticket/47912
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?
389-users@lists.fedoraproject.org
-
Anthony Joseph Messina -
Ludwig Krispenz