Hello James,

The fact that the master is more powerfull than the replica increase the possibility to hit that bug. The bug fix is on the master side. The master is made smarter to adapt its replication flow to the speed of the consumer. The bug is fixed in 389-ds-base-1.3.3.1-10.el7 and 389-ds-base-1.2.11.15-56.el6.


What is the current version of your master ?

thanks
thierry
On 06/08/2015 09:49 AM, James James wrote:
Hi Thierry,

thanks for you answer.

I was away for a long time, this is why my post comes later .

This timing issue is coming when you try to upgrade from rhel 6 (ipa-3.0) to rhel7 (ipa4.xx) ?

I have a physical machine for the master and a VM as replica. The solution is to use a physical machine for the replica ?

How can I limit the cpu/memory in the physical machine (with cgroups ??).

Any  hints will be appreciated ..

Regards

James

2015-05-18 14:04 GMT+02:00 thierry bordaz <tbor...@redhat.com <mailto:tbor...@redhat.com>>:

    On 05/15/2015 05:11 PM, James James wrote:
    ok Rob. Thanks for your help. I will wait for the Scientific
    Linux 6.7 .

    Hi James,

    Unfortunately there is no workaround. This is a timing issue
    mostly seen when the master is more powerful than the consumer.
    If you are using VM you may try to get master/replica with nearly
    the same cpu/memory.

    thanks
    thierry


    Best.

    James

    2015-05-15 16:58 GMT+02:00 Rich Megginson <rmegg...@redhat.com
    <mailto:rmegg...@redhat.com>>:

        On 05/15/2015 08:46 AM, James James wrote:
        [root@ipa ~]#  rpm -q 389-ds-base
        389-ds-base-1.2.11.15-50.el6_6.x86_64

        Ok.  Looks like this is planned to be fixed in RHEL 6.7 with
        version 389-ds-base-1.2.11.15-56.el6

        I don't know if there are any workarounds.





        2015-05-15 16:32 GMT+02:00 Rich Megginson
        <rmegg...@redhat.com <mailto:rmegg...@redhat.com>>:

            On 05/15/2015 08:22 AM, James James wrote:
            I think that :

            Starting replication, please wait until this has completed.
            Update in progress, 127 seconds elapsed
            Update in progress yet not in progress


            looks like a time error :
            https://fedorahosted.org/freeipa/ticket/4756

            That issue should have been fixed in 389-ds-base-1.3.3
            branch. What version of 389-ds-base? rpm -q 389-ds-base



            2015-05-15 16:00 GMT+02:00 Rich Megginson
            <rmegg...@redhat.com <mailto:rmegg...@redhat.com>>:

                On 05/15/2015 07:55 AM, James James wrote:
                Is it possible to change the nsds5ReplicaTimeout
                value to get rid of this timeout error ?

                What timeout error?


                2015-04-17 4:52 GMT+02:00 Rich Megginson
                <rmegg...@redhat.com <mailto:rmegg...@redhat.com>>:

                    On 04/15/2015 10:44 PM, James James wrote:
                    The ipareplica-install.log file in attachment
                    ...

                    Here are the pertinent bits:

                    2015-04-15T15:06:31Z DEBUG
                    wait_for_open_ports: localhost [389] timeout 300
                    2015-04-15T15:06:32Z DEBUG flushing
                    ldap://ipa.example.com:389 from SchemaCache
                    2015-04-15T15:06:32Z DEBUG retrieving schema
                    for SchemaCache url=ldap://ipa.example.com:389
                    conn=<ldap.ldapobject.SimpleLDAPObject
                    instance at 0x484f4d0>
                    2015-04-15T15:06:32Z DEBUG flushing
                    ldaps://ipa1.example.com:636 from SchemaCache
                    2015-04-15T15:06:32Z DEBUG retrieving schema
                    for SchemaCache
                    url=ldaps://ipa1.example.com:636
                    conn=<ldap.ldapobject.SimpleLDAPObject
                    instance at 0x4170290>
                    2015-04-15T15:08:44Z DEBUG Traceback (most
                    recent call last):
                      File
                    
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
                    line 382, in start_creation
                    run_step(full_msg, method)
                      File
                    
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
                    line 372, in run_step
                        method()
                      File
                    
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
                    line 368, in __setup_replica
                    r_bindpw=self.dm_password)
                      File
                    
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
                    line 969, in setup_replication
                        raise RuntimeError("Failed to start
                    replication")
                    RuntimeError: Failed to start replication

                    2015-04-15T15:08:44Z DEBUG [error]
                    RuntimeError: Failed to start replication

                    The times are a little off, but I believe this
                    corresponds to
                    [15/Apr/2015:17:08:39 +0200] - import
                    userRoot: Import complete. Processed 1539
                    entries in 126 seconds. (12.21 entries/sec)
                    [15/Apr/2015:17:08:39 +0200]
                    NSMMReplicationPlugin -
                    multimaster_be_state_change: replica
                    dc=lix,dc=polytechnique,dc=fr is coming
                    online; enabling replication

                    I don't know why setup_replication is
                    reporting an error if replication completed
                    successfully.



                    2015-04-16 2:22 GMT+02:00 Rob Crittenden
                    <rcrit...@redhat.com
                    <mailto:rcrit...@redhat.com>>:

                        Rich Megginson wrote:
                        > On 04/15/2015 02:58 PM, James James wrote:
                        >> Nothing on the replica .. maybye a
                        process on the master. How can I
                        >> check that ?
                        >
                        > I have no idea.  But it seems highly
                        unlikely that a process on the
                        > master is able to shutdown a process on
                        the replica . . .
                        >
                        > I would say that there is some problem
                        with the ipa-replica-install not
                        > properly checking the status - see below:
                        >
                        >>
                        >> 2015-04-15 21:37 GMT+02:00 Rich
                        Megginson <rmegg...@redhat.com
                        <mailto:rmegg...@redhat.com>
                        >> <mailto:rmegg...@redhat.com
                        <mailto:rmegg...@redhat.com>>>:
                        >>
                        >>  On 04/15/2015 12:43 PM, James James
                        wrote:
                        >>>    Here the log
                        >>>
                        >>>    2015-04-15 18:58 GMT+02:00 Rich
                        Megginson <rmegg...@redhat.com
                        <mailto:rmegg...@redhat.com>
                        >>>    <mailto:rmegg...@redhat.com
                        <mailto:rmegg...@redhat.com>>>:
                        >>>
                        >>>        On 04/15/2015 09:46 AM, James
                        James wrote:
                        >>>>        Hello,
                        >>>>
                        >>>>        I have been looking to solve
                        my problem but I 'm asking for
                        >>>>        some help.
                        >>>>
                        >>>>        The replication begins but
                        cannot be completed ....
                        >>>>
                        >>>>        I want to install a new fresh
                        replica but I've always got
                        >>>>        this error :
                        >>>>
                        >>>>  [21/35]: configure dirsrv ccache
                        >>>>  [22/35]: enable SASL mapping fallback
                        >>>>  [23/35]: restarting directory server
                        >>>>  [24/35]: setting up initial replication
                        >>>>  Starting replication, please wait
                        until this has completed.
                        >>>>        Update in progress, 127
                        seconds elapsed
                        >>>>        Update in progress yet not in
                        progress
                        >>>>
                        >>>>        Update in progress yet not in
                        progress
                        >>>
                        >
                        > in progress yet not in progress???? The
                        error log below clearly shows
                        > that replica init succeeded after 127
                        seconds.
                        >
                        > IPA-ers - wasn't there some bug about
                        checking replica status properly?
                        >

                        The loop looks at
                        nsds5BeginReplicaRefresh,
                        nsds5replicaUpdateInProgress
                        and nsds5ReplicaLastInitStatus.

                        It loops looking for
                        nsds5BeginReplicaRefresh. If there is no
                        value it
                        prints "Update in progress, %d seconds
                        elapsed". Once it gets a status,
                        the update is done, and it looks at
                        nsds5ReplicaLastInitStatus. If it
                        isn't empty, doesn't include 'replica
                        busy' or 'Total update succeeded'
                        then it looks to see if
                        nsds5replicaUpdateInProgress is TRUE. If
                        it is,
                        ir prints Update in progress yet not in
                        progress and tries the loop again.

                        AFAICT this part of a replica install
                        doesn't restart 389-ds.

                        /var/log/ipareplica-install.log may hold
                        some details.

                        rob















-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to