Re: iprop: Problem forcing complete database sync

2017-10-12 Thread Nico Williams
On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote: > On 2017-10-06 10:03:37, Nico Williams wrote: > > Trungcating the log is not the same thing as resetting it, and preserves > > the version number. > > To summarize this tread: The --reset flag should currently not be used > in a

Re: iprop: Problem forcing complete database sync

2017-10-12 Thread Patrik Lundin
On 2017-10-06 10:03:37, Nico Williams wrote: > Trungcating the log is not the same thing as resetting it, and preserves > the version number. To summarize this tread: The --reset flag should currently not be used in a production systems since ipropd-master is unable to parse the resulting log

Re: iprop: Problem forcing complete database sync

2017-10-09 Thread Nico Williams
On Mon, Oct 9, 2017 at 3:40 PM Nico Williams wrote: > On Mon, Oct 9, 2017 at 3:19 AM Harald Barth wrote: > >> >> Have I got this right? >> >> 1. Does write_dump(context, s, database, current_version) always write >> a comptele dump no matter the value of

Re: iprop: Problem forcing complete database sync

2017-10-09 Thread Nico Williams
On Mon, Oct 9, 2017 at 3:19 AM Harald Barth wrote: > > Have I got this right? > > 1. Does write_dump(context, s, database, current_version) always write > a comptele dump no matter the value of current_version? > > 2. Does write_dump(context, s, database, current_version) only use >

Re: iprop: Problem forcing complete database sync

2017-10-09 Thread Harald Barth
Have I got this right? 1. Does write_dump(context, s, database, current_version) always write a comptele dump no matter the value of current_version? 2. Does write_dump(context, s, database, current_version) only use current_version to set the version of the dump? 3. I's named "send_complete",

Re: iprop: Problem forcing complete database sync

2017-10-07 Thread Henry B (Hank) Hotz, CISSP
On thing that’s conspicuously missing from this discussion is any historical context for how the version numbers are *supposed* to be handled. It seems like most of these problems are recent, or at least recent-ish. IIUC the deal is (should be? used to be? Please correct!): 1) On initial

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Nico Williams
We're going to revisit the when-to-send_complete() logic. We've had one case where a slave was stuck doing repeated send_completes. It's also problematic that send_complete() is synchronous and ipropd-master does not fork() and is not multi-threaded. We've seen a case where one send_complete

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Nico Williams
On Fri, Oct 06, 2017 at 04:48:20PM +0200, Patrik Lundin wrote: > On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote: > > It shouldn't be needed. First, a full dump is automatically triggered > > if the master doesn't have enough log entries to bring the slave from > > its current version to the

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Nico Williams
On Fri, Oct 06, 2017 at 09:29:33AM -0400, Jeffrey Hutzelman wrote: > On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote: > It's also not necessary and in fact potentially harmful to check the > master's version for 0. A real database can never be at version 0, so > if you see

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Nico Williams
Trungcating the log is not the same thing as resetting it, and preserves the version number.

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Patrik Lundin
On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote: > > It shouldn't be needed. First, a full dump is automatically triggered > if the master doesn't have enough log entries to bring the slave from > its current version to the master version. so if a slave us at version > 0, you either get a

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Jeffrey Hutzelman
On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote: > >Removing that without putting something else in place (and I would say >not only s->version == 0 but even current_version == 0 should trigger >a send_complete) was probably a bad idea. It shouldn't be needed. First, a full

Re: iprop: Problem forcing complete database sync

2017-10-06 Thread Harald Barth
> From what I can tell iprop has no way to differentiate between "I have no > database, therefore I consider myself at version 0" and "I have a database, in > sync with version 0". I think (and hope) that a database is never at version 0 as it should be created at version 1. So after the

Re: iprop: Problem forcing complete database sync

2017-10-05 Thread Harald Barth
By looking at the code of send_diffs (ipropd_master.c:666) it looks to me that there somewhere at the beginning of that long function, before plowing through the log on the master, there should be something like if (current_version == 0 || s->version == 0){ (...) return send_complete

iprop: Problem forcing complete database sync

2017-10-04 Thread Patrik Lundin
Hello, I am currently testing a 7.4.0 based KDC master with a slave running the 7.1.0 version available in Debian Stretch. Currently I am experiencing problems with getting iprop to force a complete sync of the database. As is stated in iprop-log(8) truncating the log with --reset should cause