Thanks Todd.
Much appreciated.
Franco
- Original Message -
From: "Todd Lipcon"
To: user@kudu.apache.org
Sent: Wednesday, November 1, 2017 9:46:15 PM
Subject: Re: Error message: 'Tried to update clock beyond the max. error.'
Thanks Franco. I filed https://is
d the max.
> error.
>
> Franco
>
>
> --
> *From: *"Todd Lipcon"
> *To: *user@kudu.apache.org
> *Sent: *Wednesday, November 1, 2017 8:00:09 PM
> *Subject: *Re: Error message: 'Tried to update clock beyond the max.
> error.'
>
>
> What
nt: Wednesday, November 1, 2017 8:00:09 PM
Subject: Re: Error message: 'Tried to update clock beyond the max. error.'
What's the full log line where you're seeing this crash? Is it coming from
tablet_bootstrap.cc, raft_consensus.cc, or elsewhere?
-Todd
2017-1
Actually I think I understand the root cause of this. I think at some point
NTP can switch the clock from a microseconds-based mode to a
nanoseconds-based mode, at which point Kudu starts interpreting the results
of the ntp_gettime system call incorrectly, resulting in incorrect error
estimates and
What's the full log line where you're seeing this crash? Is it coming from
tablet_bootstrap.cc, raft_consensus.cc, or elsewhere?
-Todd
2017-11-01 15:45 GMT-07:00 Franco Venturi :
> Our version is kudu 1.5.0-cdh5.13.0.
>
> Franco
>
>
>
>
>
--
Todd Lipcon
Software Engineer, Cloudera
Our version is kudu 1.5.0-cdh5.13.0.
Franco
processes were down again, this
> time with this new time sync related error message:
>
>
> Tried to update clock beyond the max. error.
>
>
> To try to address this new error, I brought down all the Kudu processes,
> stopped ntpd, resync'd the time on all the server
tpd, and a
few minutes later I restarted all the Kudu processes (one master and three
tablet servers).
A few minutes later a couple of those Kudu processes were down again, this time
with this new time sync related error message:
Tried to update clock beyond the max. error.
To try to a
