[ntp:questions] ntpd sets clock to the year 1939

Richard B. gilbert rgilbert88 at comcast.net
Mon Mar 26 18:50:46 UTC 2007


Robert Dodier wrote:
> Hello,
> 
> I am working with embedded Linux systems (Gumstix) which appear to
> lack
> a persistent clock so whenever they are rebooted, their system clocks
> go
> back to January 1, 1970. I am hoping to use ntpd to set the clock on
> these
> systems but I am getting an unexpected result.
> 
> When I run ntpd on the Gumstix, without the -g option it complains
> that the
> time difference between the local clock and the server is too great.
> OK, I expected that. However, when I run it again with -g, ntpd
> happily
> makes a big adjustment in the local time ... changing it from 1970 to
> 1939 for some reason. I tried a couple of different servers but got
> the same
> result.
> 
> Here's the content of /etc/ntp.conf (sans most of the comments):
> 
> restrict default nomodify notrap noquery
> restrict 127.0.0.1
> # server 0.pool.ntp.org
> # server 1.pool.ntp.org
> # server 2.pool.ntp.org
> server time.cachenetworks.com
> driftfile /var/lib/ntp/drift
> 
> Here's the output from /var/log/messages.
> The first output is without -g option and second one is with -g.
> ...
> Dec 31 16:04:34 gumstix daemon.err ntpd[447]: time correction of
> -972551638 seconds exceeds sanity limit (1000); set clock manually to
> the correct UTC time.
> ...
> Mar  8 06:51:15 gumstix daemon.notice ntpd[467]: time reset
> -972551637.925997 s
> 
> Now -972551637 = -31 years, approximately, so that's how the date is
> set to 1939
> from 1970. However, it is not a simple sign inversion: the correct
> time adjustment
> should be more like +37 years.
> 
> I'm really stumped. Any light you can shed on this problem is much
> appreciated.
> 
> Robert Dodier
> 

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.




More information about the questions mailing list