[389-users] csngen_adjust_time: adjustment limit exceeded

Juan Asensio Sánchez okelet at gmail.com
Mon Aug 16 08:29:09 UTC 2010


Hi

I am having problems with some replicas. Using 389 DS 1.2.5, CentOS 5.5. A
few days ago, a server crashed, and when restarted, it had the time of the
crash (more than 1 day). Just after the server started up, the time was sync
with the NTP, but when dirsrv started, the time was wrong. Since that, the
replication agreements of the multimaster database it hosts, is giving
problems: "-1 Incremental update has failed and requires administrator
actionSystem error". So, I am trying to initialize the rest of the servers
from the "main" (tha server where the most os the modifications are done, we
have 6 servers in multimaster mode for the database, and other databases in
hub mode). When I try to initialize the server, i get this error on the
supplier: "Replication error acquiring replica: excessive clock skew. Error
Code: 2", although all the servers have the same time. In the consumer log,
I get this:

[16/Aug/2010:10:04:58 +0200] - csngen_adjust_time: adjustment limit
exceeded; value - 1390893, limit - 86400
[16/Aug/2010:10:04:58 +0200] - CSN generator's state:
[16/Aug/2010:10:04:58 +0200] -  replica id: 5
[16/Aug/2010:10:04:58 +0200] -  sampled time: 1281945898
[16/Aug/2010:10:04:58 +0200] -  local offset: 0
[16/Aug/2010:10:04:58 +0200] -  remote offset: 0
[16/Aug/2010:10:04:58 +0200] -  sequence number: 111

I am stuck now. Tried to export database from supplier, import it in the
consumer, and try to reinitialize without success. Also tried to disable the
replica on both supplier and consumer, reenable it, and recreate the
replication agreements without success. I have seen this bug
https://bugzilla.redhat.com/show_bug.cgi?id=233642, but we have version
1.2.5, so his bug is supposed to be fixed. This is the result of the
readNsState.py on the supplier (only for the database giving problems):

nsState is BAAAADT2aEwAAAAAAQAAAAQAAAA=
Little Endian
For replica cn=replica, cn="dc=XXXXX,dc=XXXX", cn=mapping tree, cn=config
  fmtstr=[H2x3IH2x]
  size=20
  len of nsstate is 20
  CSN generator state:
    Replica ID    : 4
    Sampled Time  : 1281947188
    Gen as csn    : 4c68f634000400040000
    Time as str   : Mon Aug 16 10:26:28 2010
    Local Offset  : 0
    Remote Offset : 1
    Seq. num      : 4
    System time   : Mon Aug 16 10:26:42 2010
    Diff in sec.  : 14
    Day:sec diff  : 0:14


And this in the consumer:

nsState is BQAAAPv1aEwAAAAAAAAAAAIAAAA=
Little Endian
For replica cn=replica, cn="dc=XXX,dc=XXXXX", cn=mapping tree, cn=config
  fmtstr=[H2x3IH2x]
  size=20
  len of nsstate is 20
  CSN generator state:
    Replica ID    : 5
    Sampled Time  : 1281947131
    Gen as csn    : 4c68f5fb000200050000
    Time as str   : Mon Aug 16 10:25:31 2010
    Local Offset  : 0
    Remote Offset : 0
    Seq. num      : 2
    System time   : Mon Aug 16 10:26:24 2010
    Diff in sec.  : 53
    Day:sec diff  : 0:53

I think the low remote offset (accoriding to the bug this number should
increase with the changes) is due to the initialization of the database from
the exports. Any help? All replication agreements are a disaster now :S.

Regards and thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20100816/6d58c081/attachment.html>


More information about the 389-users mailing list