[ntp:questions] ntpd sets clock to the year 1939
usenet at fordson.demon.co.uk
Tue Mar 27 16:09:46 UTC 2007
On Tue, 27 Mar 2007 11:04:02 -0400, "Richard B. gilbert"
<rgilbert88 at comcast.net> wrote:
>Marc Brett wrote:
>> On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
>> <rgilbert88 at comcast.net> wrote:
>>>Robert Dodier wrote:
>>>>On Mar 26, 12:50 pm, "Richard B. gilbert" <rgilber... at comcast.net>
>>>>>I believe that there is a limit to the date/time range that ntpd can
>>>>>handle and that it's something like 36 years. Try setting the date
>>>>>manually to something a little closer to being current. If it's off by
>>>>>less than 36 years, I think ntpd will handle it correctly. A startup
>>>>>script that set the date to a reasonable approximation; e.g. 2007 would
>>>>>probably solve your problem and work for the next 36 years or so.
>>>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
>>>>able to handle the rest. It seems odd to me that ntpd gets confused by
>>>>too large a time difference, but oh well, it's OK the way it is.
>>>It's hardly ever a problem since most systems have a hardware clock of
>>>some sort that can supply a reasonable starting point. In 2007, I don't
>>>think that 1970-is a reasonable starting point.
>> "Be liberal in what you accept, conservative in what you send."
>> We may not think that 1970 is a reasonable starting point, but these systems
>> exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
>> 0 is not exactly an unreasonable starting date for a system with no hardware
>> clock and no DHCP-specified NTP server.
>> It's unfortunate that applications (especially an application dedicated to
>> keeping the correct time, fer cryin out loud) fall over when faced with such a
>> time value, but whose fault is that?
>The opposite argument would be that it's not reasonable for ntpd to make
>a "leap of faith" and jump the time by 36 years!
But 26 years, say, is perfectly reasonable?
>Ntpd is designed to
>consider a clock that's off by 1024 seconds or more as a situation it is
>not equipped to handle. Ntpd is behaving as it's designed and
>documented to behave.
But it isn't. The "ntpd -g" documentation says:
Normally, ntpd exits with a message to the system log if the offset exceeds the
panic threshold, which is 1000 s by default. This option allows the time to be
set to any value without restriction; however, this can happen only once.
"Without restriction" means, to me, that time jumps of 26 years, 36 years, or 46
years are all perfectly fine.
>The source is available and anyone with the necessary skills can modify
>it to handle special cases like this. Anyone lacking the necessary
>skills can pay someone with the skills to do the work.
Maybe the gumstix folk can be persuaded...
More information about the questions