[Freeipa-users] Replication seems to begin but failed after 127 seconds ...
thierry bordaz
tbordaz at redhat.com
Mon Jun 8 08:25:04 UTC 2015
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 <tbordaz at redhat.com
> <mailto:tbordaz at 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 <rmeggins at redhat.com
>> <mailto:rmeggins at redhat.com>>:
>>
>> On 05/15/2015 08:46 AM, James James wrote:
>>> [root at 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
>>> <rmeggins at redhat.com <mailto:rmeggins at 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
>>>> <rmeggins at redhat.com <mailto:rmeggins at 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
>>>>> <rmeggins at redhat.com <mailto:rmeggins at 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
>>>>>> <rcritten at redhat.com
>>>>>> <mailto:rcritten at 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 <rmeggins at redhat.com
>>>>>> <mailto:rmeggins at redhat.com>
>>>>>> >> <mailto:rmeggins at redhat.com
>>>>>> <mailto:rmeggins at 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 <rmeggins at redhat.com
>>>>>> <mailto:rmeggins at redhat.com>
>>>>>> >>> <mailto:rmeggins at redhat.com
>>>>>> <mailto:rmeggins at 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150608/20e7f3a7/attachment.htm>
More information about the Freeipa-users
mailing list