[389-users] Re: replication problems

On 5/12/20 11:12 AM, Alberto Viana wrote: Hi Guys, One last doubt, I saw that was pushed into master branch, what about others branches? It should yes,  I added a note to the ticket to get this pushed back to 1.4.1 and up. Thanks Alberto Viana On Mon, May 11, 2020 at 12:55 PM thierry

[389-users] Re: replication problems

Hi Guys, One last doubt, I saw that was pushed into master branch, what about others branches? Thanks Alberto Viana On Mon, May 11, 2020 at 12:55 PM thierry bordaz wrote: > Hi Alberto, > > The upstream ticket is https://pagure.io/389-ds-base/issue/51082 with a > pending PR under review. > >

[389-users] Re: replication problems

Hi Alberto, The upstream ticket is https://pagure.io/389-ds-base/issue/51082 with a pending PR under review. best regards thierry On 5/11/20 4:48 PM, Alberto Viana wrote: Hi Thierry, So I think this is good news. Once I'm waiting for a fix and affects my production servers (high

[389-users] Re: replication problems

Hi Thierry, So I think this is good news. Once I'm waiting for a fix and affects my production servers (high availability), can you post here the ticket so I can follow up the fix? I will check out and read about the asan. Thanks a lot. Alberto Viana On Mon, May 11, 2020 at 10:21 AM thierry

[389-users] Re: replication problems

Hi Alberto, I think I reproduced the same crash locally: (gdb) where #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1  0x7f4137c13972 in __GI_abort () at abort.c:100 #2  0x7f4137e6c241 in PR_Assert (     s=0x7f4138437420 "(vs->sorted ==

[389-users] Re: replication problems

William, It's suppose to be production, but once it's not working (the replication) I just left one 389 as main server, so I can do any test as I want. I have no idea how to do that, can you point me in the right direction? Thanks Alberto Viana On Thu, May 7, 2020 at 9:09 PM William Brown

[389-users] Re: replication problems

Is this a development/debug build? Do you have a reproducer? It would be interesting to run this under ASAN ... > On 7 May 2020, at 22:31, Alberto Viana wrote: > > William, > > Here's: > Assertion failure: (vs->sorted == NULL) || (vs->num < > VALUESET_ARRAY_SORT_THRESHOLD) || ((vs->num >=

[389-users] Re: replication problems

> On 6 May 2020, at 22:40, Alberto Viana wrote: > > William, > > Here's: > > (gdb) frame 3 > #3 0x77b71627 in slapi_valueset_done (vs=0x7fffac022aa8) at > ldap/servers/slapd/valueset.c:471 > 471PR_ASSERT((vs->sorted == NULL) || (vs->num < > VALUESET_ARRAY_SORT_THRESHOLD)

[389-users] Re: replication problems

William, Here's: (gdb) frame 3 #3 0x77b71627 in slapi_valueset_done (vs=0x7fffac022aa8) at ldap/servers/slapd/valueset.c:471 471PR_ASSERT((vs->sorted == NULL) || (vs->num < VALUESET_ARRAY_SORT_THRESHOLD) || ((vs->num >= VALUESET_ARRAY_SORT_THRESHOLD) && (vs->sorted[0] <

[389-users] Re: replication problems

So reading these frames, it's likely that this is the assert condition failing: (vs->num >= VALUESET_ARRAY_SORT_THRESHOLD) && (vs->sorted[0] < vs->num) This is because vs->sorted exists, and vs->num >= threshhold (10), so as a result, this would indicate that vs->sorted[0] has a problem where

[389-users] Re: replication problems

William, Here's: Frame9: https://gist.github.com/albertocrj/87bf4a010bf2f7e1f97ef3ee72ee44df Frame7: https://gist.github.com/albertocrj/840f15e5df10cad0e2977cd030abdba4 Frame6: https://gist.github.com/albertocrj/befb7144b86bc4af86b9a2e0be0293a1 Thank you Alberto Viana On Wed, Apr 22, 2020

[389-users] Re: replication problems

> On 23 Apr 2020, at 06:59, Alberto Viana wrote: > > Mark, > > On frame 9: > > It's go until p *mod->mod_bvalues[20] > > (gdb) p *mod->mod_bvalues[21] > Cannot access memory at address 0x0 > > On frame 7: > It's go until p *replacevals[20] > > (gdb) p *replacevals[21] > Cannot access

[389-users] Re: replication problems

Mark, On frame 9: It's go until p *mod->mod_bvalues[20] (gdb) p *mod->mod_bvalues[21] Cannot access memory at address 0x0 On frame 7: It's go until p *replacevals[20] (gdb) p *replacevals[21] Cannot access memory at address 0x0 On frame 6: (gdb) frame 6 #6 0x77ada6fa in

[389-users] Re: replication problems

Goto frame 9 and start printing the mod: (gdb) p *mod (gdb) print i (gdb) p *mod->mod_bvalues[0] (gdb) p *mod->mod_bvalues[1] ... Keep doing that unitl its NULL Then goto frame 7 (gdb) p *replacevals (gdb) p *replacevals[0] (gdb) p *replacevals[1] --- Keeping doing this until its NULL

[389-users] Re: replication problems

Mark, Yes, I'm in frame 3, and No, I do not know what modification is, sorry. I think thats what I'm trying to find out, why one of the servers always crash if I enable the replication between 2 389. Maybe reconfigure my replication, enable debug log and see where stops? What else can I do?

[389-users] Re: replication problems

On 4/22/20 3:27 PM, Alberto Viana wrote: Mark, Here's: (gdb) where #0  0x7455399f in raise () at /lib64/libc.so.6 #1  0x7453dcf5 in abort () at /lib64/libc.so.6 #2  0x75430cd0 in PR_Assert () at /lib64/libnspr4.so #3  0x77b71627 in slapi_valueset_done

[389-users] Re: replication problems

Mark, Here's: (gdb) where #0 0x7455399f in raise () at /lib64/libc.so.6 #1 0x7453dcf5 in abort () at /lib64/libc.so.6 #2 0x75430cd0 in PR_Assert () at /lib64/libnspr4.so #3 0x77b71627 in slapi_valueset_done (vs=0x7fff8c022aa8) at

[389-users] Re: replication problems

On 4/22/20 3:15 PM, Alberto Viana wrote: William, Here's: (gdb) frame 3 #3  0x77b71627 in slapi_valueset_done (vs=0x7fff8c022aa8) at ldap/servers/slapd/valueset.c:471 471        PR_ASSERT((vs->sorted == NULL) || (vs->num < VALUESET_ARRAY_SORT_THRESHOLD) || ((vs->num >=

[389-users] Re: replication problems

William, Here's: (gdb) frame 3 #3 0x77b71627 in slapi_valueset_done (vs=0x7fff8c022aa8) at ldap/servers/slapd/valueset.c:471 471PR_ASSERT((vs->sorted == NULL) || (vs->num < VALUESET_ARRAY_SORT_THRESHOLD) || ((vs->num >= VALUESET_ARRAY_SORT_THRESHOLD) && (vs->sorted[0] <

[389-users] Re: replication problems

> On 18 Apr 2020, at 02:55, Alberto Viana wrote: > > Hi Guys, > > I build my own packages (from source), here's the info: > 389-ds-base-1.4.2.8-20200414gitfae920fc8.el8.x86_64.rpm > 389-ds-base-debuginfo-1.4.2.8-20200414gitfae920fc8.el8.x86_64.rpm >

[389-users] Re: replication problems

Hi Guys, I build my own packages (from source), here's the info: 389-ds-base-1.4.2.8-20200414gitfae920fc8.el8.x86_64.rpm 389-ds-base-debuginfo-1.4.2.8-20200414gitfae920fc8.el8.x86_64.rpm python3-lib389-1.4.2.8-20200414gitfae920fc8.el8.noarch.rpm I'm running in centos8. Here's what I could

[389-users] Re: replication problems

> On 1 Apr 2020, at 05:18, Mark Reynolds wrote: > > > On 3/31/20 1:36 PM, Alberto Viana wrote: >> Hey Guys, >> >> 389-Directory/1.4.2.8 >> >> 389 (master) <=> 389 (master) >> >> In a master to master replication, start to see this error : >> [31/Mar/2020:17:30:52.610637150 +] - WARN -

[389-users] Re: replication problems

On 3/31/20 1:36 PM, Alberto Viana wrote: Hey Guys, 389-Directory/1.4.2.8 389 (master) <=> 389 (master) In a master to master replication, start to see this error : [31/Mar/2020:17:30:52.610637150 +] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload -

[389-users] Re: Replication problems

On 1/29/19 1:16 PM, Mitch Patenaude wrote: On 1/29/19, 10:12 AM, "Mitch Patenaude" wrote: additional info: Unknown attribute nsslapd-errorlog-loglevel will be ignored Figured out that it was suppoed to be nsslapd-errorlog-level. I should have read the docs. Me too :-/

[389-users] Re: Replication problems

On 1/29/19, 10:12 AM, "Mitch Patenaude" wrote: additional info: Unknown attribute nsslapd-errorlog-loglevel will be ignored Figured out that it was suppoed to be nsslapd-errorlog-level. I should have read the docs. ___

[389-users] Re: Replication problems

From: Mark Reynolds ldapmodify -D "cn=directory manager" -W (Hit send too soon) When I try this, I get: intdns2-02-lv:~ root# ldapmodify -x -h localhost -D 'cn=directory manager' -W -f enable_replication_loggging.ldif  Enter LDAP Password:  modifying entry "cn=config" ldap_modify:

[389-users] Re: Replication problems

On 1/28/19 8:13 PM, Mitch Patenaude wrote: On 1/28/19, 9:20 AM, "Mark Reynolds" wrote: [...] If that is not useful then turning on replication logging would be the next step. Trying to track the CSN only yielded that the same CSN was tried *many* times without success. I can't

[389-users] Re: Replication problems

On 1/28/19 12:06 PM, Mitch Patenaude wrote: I’ve got a somewhat complex replication arrangement. There are 6 masters total. 09-11-13 |\/ | \/| |/\ | /\| 10-12-14 So 11 and 12 replicate to all other servers, 09 and 10 replicate to each other and 11 and 12, and 13 & 14 replication