[Freeipa-users] Replication seems to begin but failed after 127 seconds ...
James James
jreg2k at gmail.com
Mon Jun 8 10:30:09 UTC 2015
My master version is 389-ds-base-1.2.11.15-50.el6_6.x86_64 .
Thanks.
2015-06-08 10:25 GMT+02:00 thierry bordaz <tbordaz at redhat.com>:
> 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>:
>
>> 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>:
>>
>>> 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>:
>>>
>>>> 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>:
>>>>
>>>>> 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>:
>>>>>
>>>>>> 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>:
>>>>>>
>>>>>>> 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>>:
>>>>>>> >>
>>>>>>> >> 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>>:
>>>>>>> >>>
>>>>>>> >>> 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/a4e034a3/attachment.htm>
More information about the Freeipa-users
mailing list