<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/21/2015 09:15 AM, Ludwig Krispenz wrote: </div> <blockquote cite="mid:555DDA58.4050403@redhat.com" type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <div class="moz-cite-prefix">On 05/21/2015 03:04 PM, Janelle wrote: </div> <blockquote cite="mid:555DD7D8.6080104@gmail.com" type="cite">On 5/21/15 5:49 AM, Rich Megginson wrote: <blockquote type="cite">On 05/21/2015 06:25 AM, Janelle wrote: <blockquote type="cite">On 5/21/15 5:20 AM, thierry bordaz wrote: <blockquote type="cite">Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f718000300170000 was applied. Note that the two hexa values of replica 23 changed (5545d61f000200170000 5552f718000300170000 vs 5553e3a3000000170000 55543240000300170000). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry </blockquote> Just to help me -- what is the best way to enable the logging level you need? </blockquote> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting">http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting</a> The Replication log level. <blockquote type="cite">I thought I did it correctly adding to ldif.dse, but I don't think it took. </blockquote> You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. <blockquote type="cite">I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? </blockquote> The Replication log level. <blockquote type="cite">~Janelle </blockquote> </blockquote> How do I kill one of the ldapmodify "cleans" I had started but seems to be stuck: </blockquote> abort should be done by ldapmodify similar to starting it: ldapmo <pre><code>ldapmodify .... dn: cn=abort 222, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject cn: abort 222 replica-base-dn: dc=example,dc=com replica-id: 222 replica-certify-all: no --> if set to "no" the task does not wait for all the replica servers to have been sent the abort task, or be online, before completing. If set to "yes", the task will run forever until all the configured replicas have been aborted. Note - the orginal default was "yes", but this was changed to "no" on 4/21/15. It is best to set this attribute anyway, and not rely on what the default is. </code></pre> if it doesn't work we have to ask Mark :-) </blockquote> The abort task should work, assuming replica-certify-all is to "no". If there is still a problem you can always monitor the errors log (/var/log/dirsrv/slapd-INSTANCE/errors), and grep for "CleanAllRUV" to sort the output. Mark <pre><code> </code></pre> <blockquote cite="mid:555DDA58.4050403@redhat.com" type="cite"> <blockquote cite="mid:555DD7D8.6080104@gmail.com" type="cite"> CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running It has been 45 minutes and still nothing, so I want to kill it and try again. ~J </blockquote> </blockquote> </body> </html>