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 <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]>: >>>>> >>>>>> 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 <[email protected]>: >>>>>> >>>>>>> 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 <[email protected] >>>>>>> >> <mailto:[email protected]>>: >>>>>>> >> >>>>>>> >> On 04/15/2015 12:43 PM, James James wrote: >>>>>>> >>> Here the log >>>>>>> >>> >>>>>>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson < >>>>>>> [email protected] >>>>>>> >>> <mailto:[email protected]>>: >>>>>>> >>> >>>>>>> >>> 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
