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

Answer 1

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

Answer 2

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.

Answer 3

Syncing to the local time source, when none actually exists, is a great way to have your clock go haywire. You discovered that the hard way (as did I some time ago). This is intended for situations where you have a GPS, atomic clock, or something related which is physically conected to the machine. If you don't have such hardware, disable it.

Answer 4

Syncing to local clock might be good idea, if some other system running on the same hardware syncs the local clock. Example: on Host1, VM1 runs ntp and syncs to some public ntp servers(and is, say, stratum 3). on Host1, VM2, VM3, VM4, ... run ntp and sync to local clock.

As long as VM1 is running, everything should be fine, right?

IMHO, ntp normally does sync the hardware clock "in small steps", think of "continously", so "hwclock -wu" at shutdown is not needed.