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 offset 2141299826.398106 sec
Aug 20 17:06:20 voyage ntpdate[1710]: step time server offset 2141299826.401065 sec
Jun 28 06:36:47 voyage ntpdate[1744]: step time server 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?

  • 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 Dec 19 '14 at 7:22

[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.


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
  • 3
    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
  • Like @Gilles said, multiple ntpdate requests should be harmless. Ntpdate should be creating a lock file which prevents concurrent runs. If you are seeing problems from multiple ntpdate runs due to your different indexes coming up in quick succession, then maybe there's some sort of race condition, which is a bug which should be reported. I'm sceptical though about whether the problem is as you describe it. – mc0e Dec 28 '14 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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