Kevin M. Myer wrote: > Quoting Richard Megginson <rmeggins at redhat.com>: > >> Kevin M. Myer wrote: >> >>> Quoting David Boreham <david_list at boreham.org>: >>> >>>> Try looking in the access and error logs on the replica server (the >>>> server that is receiving this update). >>>> That should tell us which operation is failing. Exactly what is >>>> going on I'm not sure, I've not seen a >>>> problem like this before. Perhaps someone else on the list has. >>> >>> >>> >>> Here's the action its trying to perform: >>> >>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=3 EXT >>> oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" >>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=3 RESULT err=0 tag=120 >>> nentries=0 etime=0 >>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=4 DEL >>> dn="uid=<username>,ou=people,dc=base" >>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=4 RESULT err=1 tag=107 >>> nentries=0 etime=0 csn=43a2c9d8000000010000 >>> [16/Dec/2005:09:06:18 -0500] conn=900959 op=5 EXT >>> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" >>> >>> The replication to the slave (garnet) did occur properly for the >>> account that was being deleted. >> >> >> Is this the access log from one of the masters? > > > Yes, its from the master that the changes were sent to. > >>> Its also not inhibiting other changes from occuring in the the same >>> replication session. I just made a minor modification to my account >>> and it replicated while the deletion of the account giving errors >>> failed. I restarted the server that was receiving the changes, and >>> now the deletion operation that was failing isn't occuring at all :/ >>> So I guess I'll just manually delete the account, since the one >>> master seems to be convinced that the change went through. >> >> >> So after the restart, everything is ok? > > > Unfortunately, no. What has stopped is the attempt to do the > replication from the master where the initial change was committed. > Further, if I try to manually delete the entry from the master the > changes were to be replicated to, I get the same operation error. > > [17/Dec/2005:14:07:41 -0500] conn=471 fd=210 slot=210 connection from > XX.XX.XX.XX to XX.XX.XX.XX > [17/Dec/2005:14:07:41 -0500] conn=471 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [17/Dec/2005:14:07:41 -0500] conn=471 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [17/Dec/2005:14:07:41 -0500] conn=471 op=1 DEL > dn="uid=<username>,ou=People,dc=base" > [17/Dec/2005:14:07:41 -0500] conn=471 op=1 RESULT err=1 tag=107 > nentries=0 etime=0 csn=43a461fe000000650000 > [17/Dec/2005:14:07:41 -0500] conn=471 op=2 UNBIND > [17/Dec/2005:14:07:41 -0500] conn=471 op=2 fd=210 closed - U1 > > Now to the best of my knowledge, this server has not gone down > uncleanly, and its only this one entry that is causing problems. So > ideas on what to try next, or how I might fix it? I think you should just re-initialize it e.g. reinit this master from the other master. > > Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20051219/e3fdea4e/attachment.bin
