Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am running Voyage Linux (a Debian-based distribution) and am having trouble getting the correct date. When I look in /var/log/daemon.log I see the following:

Nov 18 11:04:07 voyage ntpdate[1676]: step time server 203.97.109.165 offset 2141299826.398106 sec
Aug 20 17:06:20 voyage ntpdate[1710]: step time server 119.47.118.129 offset 2141299826.401065 sec
Jun 28 06:36:47 voyage ntpdate[1744]: step time server 203.97.109.165 offset 2141299826.460901 sec

The correct date is Nov 18 11:04:07 but it is getting changed to the middle of June. How can I fix this?

share|improve this question
    
What happens if you run these commands after you've finished booting? If you can reproduce the problem, please post traces obtained with ntpdate -d. –  Gilles Nov 18 '11 at 1:15
    
The /etc/network/if-up.d/ntpdate script actually runs ntpdate-debian -s so the output of ntpdate-debian -s -d is at pastebin.com/jEUQMdS0. Bearing in mind that now I have applied my fix, there might not be anything wrong with it. –  DanielGibbs Nov 18 '11 at 1:24
    
Ah, the cause of the 1944 start date is No usable clock interface found. from hwclock. Looking into that now. –  DanielGibbs Nov 18 '11 at 2:21
    
And the fix for that is at comments.gmane.org/gmane.linux.distributions.voyage.general/… –  DanielGibbs Nov 18 '11 at 2:54
    
That's not June of the current year. I'd never really thought much about syslog not recording the year. –  mc0e 5 hours ago

2 Answers 2

up vote 2 down vote accepted

I found the solution on this website. NTPdate was trying to update the date each time an interface went up, which in my case was three times during the boot process. So I modified /etc/network/if-up.d/ntpdate to only run ntpdate if eth0 goes up by adding the following to the top of the script:

# Only update the date if eth0 goes up.
if [ "$IFACE" != eth0 ]; then
    exit 0
fi
share|improve this answer
2  
There's probably something else that you need to fix. Making several ntpdate requests should be harmless. The insanely large offset you see (67-odd years, about 71.5 days short of 2³¹ seconds) is not normal. –  Gilles Nov 18 '11 at 1:14
    
When ntpdate fails to run at all (usually if I've broken a script somewhere) the system defaults to January 1944, so the offset sounds about right. I'm not sure what else I need to fix, but it works fine now. –  DanielGibbs Nov 18 '11 at 1:20

[a very late answer, but added for others that might follow]

limiting which interfaces you run ntpdate for might be useful, but it sounds like your major problem is lack of functioning realtime clock hardware, hence the huge initial offset.

I suggest you look into the fake_hwclock package. From the package description:

Package: fake-hwclock (0.5)

Save/restore system clock on machines without working RTC hardware

Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform filesystem checks at every boot.

On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.