Re: 389 Ldap Cleanallruv Replica Crash

Thierry Bordaz <tbordaz@xxxxxxxxxx> · Wed, 3 May 2023 10:14:07 +0200



    Hi Juan,
    

    Thanks for raising this issue. The crash can be reproduced and I
      opened https://github.com/389ds/389-ds-base/issues/5751
    It is a side effect of a CL refactoring done in 2.x branch.
    

    best regards

      thierry

    
    On 5/2/23 21:00, Juan Quintanilla
      wrote:

    
          Hi,
          

          I recently installed 
              389-ds-base-libs-2.2.6-2.el8.x86_64 and
            389-ds-base-2.2.6-2.el8.x86_64 on an ALma Linux 8
            Server, but I'm encountering an issue with removing offline
            replicas from our existing 389 Ldap.
            

          When the command below is
            executed on one of the suppliers:
          

          dsconf INSTANCE_NAME repl-tasks
            cleanallruv --suffix "ou=sample,dc=test,dc=dom" --replica-id
            20 --force-cleaning
          

          The entry is removed from the
            ldap supplier, and when the change is sent to the secondary
            supplier it is also removed with no problem.  The issue is
            when the change is sent to the consumer, the slapd process
            will instantly crash.  When the consumer instance is brought
            back up the entry that needed to be removed is gone.
          

          Has anyone encountered a similar
            issue with the consumers crashing during a cleanallruv
            request or cleanruv?
          

          I also tried running a cleanruv
            task on each server, suppliers have no issue. When the
            command is run on the readonly consumers the slapd process
            crashes.

          
          ldapmodify -x -D "cn=manager" -W
            <<EOF

            dn: cn=replica,cn=ou\3Dsample\2Cdc\3Dtest\2Cdc\3Ddom,cn=mapping tree,cn=config

            changetype: modify

            replace: nsds5task

            nsds5task: CLEANRUV20

            EOF
          

          There is no recorded error in the logs to indicate the
            reason for the crash.
          

          Thanks!

        
                    Juan

                    
      _______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

    
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue