replication uses CSNs(change sequence numbers) to synchronize data across the topology, and it requires the times to be in sync and that time never goes backward, otherwise a new change would get an older csn and probably be ignored after repliciation.
Since it is not guaranteed that system time is always is sync and that no one plays with the time setting, replcation uses its own csn state, maintainig the local system time and remote or local offsets when differnces in time were detected. This ensures that time is in sync, as good as possible, and that time never goes backward.
Unfortunately these offsets can accumulate over time and reach a value where replication "thinks" it is insane to continue and raises the clock skew error.
In my opinion this should not be a fatal error, but right now it is, feel free to log an RFE.

Now, the csns are part of all the individual data in the servers's database, so you cannot just clean them up, also if you add a new replica it will inherit the offsets present in other servers. Unfortunately I only see the hard way to get out of this: export the data without state information(csns), reimport and reinitialize. That's in the doc you referenced


On 06/01/2017 09:29 PM, pgb205 via FreeIPA-users wrote:
I have noticed that we had a broken replication agreement between replica in amazon and on another physical node. 
I have attempted to re-initialize but received
Update failed! Status: [2 Replication error acquiring replica: excessive clock skew]

I had triple verified that time on both is correct and at most within seconds of each other.

in dirsrv logs I get 
Excessive clock skew from supplier RUV
Unable to acquire replica: error: excessive clock skew

 After doing a bit of searching I found this beauty:

The article mentions that the time skew might occur due to server being virtualied, and I'm  wondering if this is applicable to Amazon.

The steps mentioned in the article look intrusive (and intimidating) . I'm curious what other avenues are available to me to fix this?
If I blow away the replica and re-set up the new one from scratch would that fix the problem.

FreeIPA-users mailing list --
To unsubscribe send an email to

Red Hat GmbH,, Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander