RE: [chrony-dev] makestep command sometimes makes chrony stop reading its sources

["Hattink, Tjalling (FINT)" <T.Hattink@xxxxxxxx>]

>On Thu, 21 Jan 2010, Miroslav Lichvar wrote:
>
>> On Thu, Jan 21, 2010 at 03:00:19PM +0100, Hattink, Tjalling (FINT)
wrote:
>>>> The freeze is probably worth investigating.
>>>
>>> I've investigated it and it has actually nothing to do with
makestep.
>>> When I set the RTC clock 40 months back or forward in time, the
chrony
>>> daemon freezes as soon as it selects a reference clock. I think
there is
>>> an integer overflow somewhere.
>>
>> Yes, I reproduced it too. The calculated timeout for ending fast slew
>> (which should be 40 / 0.08 months) overflows, the timestamp is
>> negative, the handler is immediately called which adds the timeout
>> again...
>>
>> We can limit the timeout to something reasonable like one month or
add
>> checks for signed overflows to UTI_ functions (which will possibly
>> have a performance impact).
>>
>> How much do we care about year 2038?
>
>2038 is coming and now is probably the time to start worrying. 
>Well, we certainly should make the seconds  a time_t rather than long
>(eg in UTI_DoubleTotimeval) even if time_t is defined as long now. 
>Also I agree that they are problematic in that the routines  assume
that the double is
>less than 2 10^9 sec. which it need not be. (the usec would sure come
out
>pretty weirdly for larger numbers)
>

I'm not worrying yet about 2038 for my box, but I'm quite certain more
software
will break than just chrony around that time. It is true that you can
better try
solving it today than in 2038.

>Where is that overflow occuring? Certainly the UTI functions should be
good
>for much more than 40 months (or is it that  40/.08 months from now is
overflowing 2038?)
>  I suspect that chrony should not be trying to slew that huge a
difference
>from local time-- it should either throw an exception, or just step. 
>While the 1/8 second stepping of ntpd is silly, stepping 40 months
rather than
>slewing it for the next century sounds pretty reasonable. In fact
anything
>over a day  or certainly a year sounds reasonable to step.
>

This is also a good reason to have a configurable option that determines
when
chrony should step instead of slew. If this option is not configured
chrony
could throw an exception instead when the calculated offset is off by
for
example 1000 seconds.

--
Tjalling Hattink

---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.