luca@OpenLDAP.org wrote:

Full_Name: Luca Scamoni Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131)

consistently

Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1> Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... ldapsearch failed at P1 slave (32)!

modifications to the master are not propagated to the slaves

Yes, I see this as well. syncrepl is trying to use backend_attribute() to retrieve the underlying DB's contextCSN, but backend_attribute is discarding the current op->o_bd and using select_backend() to pick which backend to query. This is definitely the wrong behavior; op->o_bd is essentially supposed to be a constant once it is set on an operation. Operations within a backend are generally not allowed to access other backends so it should not be overriding the backend that was given to it.