2

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?

Improve this question
5
  • 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. Commented Nov 18, 2011 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. Commented Nov 18, 2011 at 1:24
  • Ah, the cause of the 1944 start date is No usable clock interface found. from hwclock. Looking into that now. Commented Nov 18, 2011 at 2:21
  • And the fix for that is at comments.gmane.org/gmane.linux.distributions.voyage.general/… Commented Nov 18, 2011 at 2:54
  • That's not June of the current year. I'd never really thought much about syslog not recording the year. Commented Dec 19, 2014 at 7:22

2 Answers 2

Reset to default
4

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

Improve this answer
3

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
Improve this answer
3
  • 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. Commented Nov 18, 2011 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. Commented Nov 18, 2011 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. Commented Dec 28, 2014 at 17:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.