Is there any reason to have ntpd sync to Local(0) if server is not used as a time source?

Question

Running CentOS release 5.8

I had a time drift issue on a server which I fixed - it was not syncing the hwclock so that on a reboot ntp would be more than 1000 seconds off and never sync time.

While investigating the problem I noticed that ntpd was synchronizing to Local(0) regularly.

Is there any reason to have ntpd configured to sync to Local(0) when this server is never going to be used as a time source?

"The Answer" - you don't need to use Undisciplined Local Clock unless you want to use this server as a local time server when connecting to other time servers fail.

Log messages from ntpd:

Jul 20 03:47:49 localhost ntpd[5441]: synchronized to 110.14.8.1, stratum 3
Jul 20 04:21:06 localhost ntpd[5441]: synchronized to LOCAL(0), stratum 10
Jul 20 04:38:09 localhost ntpd[5441]: synchronized to 110.14.8.1, stratum 3
Jul 20 04:55:26 localhost ntpd[5441]: synchronized to LOCAL(0), stratum 10

ntpd.conf:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 10.4.58.21
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

We are going to disable local-sync, but still curious why the local-sync is happening at all. We put a temporary time server in place on the same sub-net, and ntpd still syncs to local time. (* Possible answer: ntpdc -c sysinfo stats that the startum of the ntp server is 11 which is worse than the 10 we told ntpd to use for the local. Time to go look at the source for ntpd *)

Jul 24 17:11:32 localhost ntpdate[5432]: step time server 227.220.222.220 offset 1629.764734 sec
Jul 24 17:11:32 localhost ntpd[5434]: ntpd [email protected] Fri Nov 18 13:21:21 UTC 2011 (1)
Jul 24 17:11:32 localhost ntpd[5435]: precision = 1.000 usec
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface wildcard, ::#123 Disabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface eth0 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface lo, ::1#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface lo, 127.0.0.1#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: Listening on interface eth0, 192.12.140.55#123 Enabled
Jul 24 17:11:32 localhost ntpd[5435]: kernel time sync status 0040
Jul 24 17:11:32 localhost ntpd[5435]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Jul 24 17:14:48 localhost ntpd[5435]: synchronized to LOCAL(0), stratum 10
Jul 24 17:16:55 localhost ntpd[5435]: synchronized to 192.12.140.200, stratum 3
Jul 24 20:11:06 localhost ntpd[5435]: synchronized to LOCAL(0), stratum 10
Jul 24 20:20:50 localhost ntpd[5435]: synchronized to 192.12.140.200, stratum 3

Solution 1

ntpd is not responsible for syncing the local hardware clock. Normally, there is a program provided to do this. On Ubuntu the program is hwclock. It is used at bootup to setup the system date and on shutdown to update it.

I usually only configure the hardware clock as a time source on the local NTP time server. If I do configure it on clients, I set them at a higher stratum, so that the time server remains the time authority if it is reachable.

If you are using ntpd to sync with the local clock, set the hardware clock to UTC and configure your system to expect UTC from the clock at boot time. Unfortunately, this doesn't work well if you dual-boot to Windows. In that case don't use the local clock as a time source.

It appears from your output that you have one intermittent external time source and this is causing you to flip back and forth from the hardware clock. Even if it is reachable, the external time source may have lost its own synchronization and not be considered a time source. If you have a constant network connection, add a couple more time sources. If you have an intermittent network connection, either fix your hardware clock setup, or remove the hardware clock as a source.

The fact that your hardware clock is off my more than 1000 seconds at boot indicates one of two likely issues:

• The hardware clock is not set to the timezone expected by the software which sets the system time during the boot sequence.
• The battery used to keep the CMOS running when the system is powered off has died or is dying.

You can solve the sync issue at boot time by adding the -g option to the ntpd command.

Solution 2

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.

This is meant as fallback-time-source if you can not reach any official servers (any more). If you enabled a drift-file this might even keep your time in sync, since the drift-file should contain the corrective value of real-time against your local clock.

Comments

[Vincent Sartor]

BillThor's answer gave me most of the clues I needed to track down what is happen. First I don't need to have the server syncing locally since it is not a valid time server. Secondly it does seem that the battery is going bad since hwclock time is drifting wildly( it drifts even when the server is powered on, so I assume that it only runs from battery ).

[BillThor]

Most systems have at least a Time of Year (TOY) clock. While not as accurate as other sources, but usually relatively accurate. It should be fudged to a high stratum as shown so it is only used as a last resort.