Pierangelo Masarati wrote:
hyc@symas.com wrote:
Luca Scamoni wrote:
hyc@symas.com ha scritto:
Apparently the name of the entry in the consumer doesn't match the name of the entry received from the provider.
Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 done through slapcat/slapadd procedure on the master.
In frame 5, print *entry
(gdb) frame 5 #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, syncCSN=0x4d3e0388) at ../../../servers/slapd/syncrepl.c:2278 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. in ../../../servers/slapd/syncrepl.c (gdb) p *entry $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = 0, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0}
Well, that's certainly odd looking. Did you have SYNC logging at the time, do you have the log messages from just before this occurred?
Can you print out the a_desc and values of all of the attributes in entry->e_attrs ?
Howard,
what's odd is that, as far as I understand, entry->e_name is set after op->o_req_dn, inside syncrepl_message_to_entry(), which is just extracted and normalized from the message. What could perhaps happen is that dnPrettyNormal() fails (in fact its result is not checked). I'm adding a check and some logging, just in case.
Good idea.
Also, I think the original LDAP message should still be intact, in frame 6 "msg" - perhaps you can extract the DN that was actually received and figure out why it had a problem.