CentOS NTPd Problem (Mostly) Resolved

The NTPd problem that I wrestled with in CentOS 4.1 and again in CentOS 4.2 has finally been resolved.  Mostly.  I think.  The specific steps I took to resolve the issue came from a number of sources, so read on for all the details.

Since these servers are virtual servers running under VMware, I first consulted the VMware Knowledge Base and turned up this article on slow and fast clocks for Linux guest VMs.  Based on that information, I added a few extra commands to the grub configuration:

noapic nosmp nolapic clock=pit

In addition, I found a number of forum postings in various sites (too many to list or link here) that referenced problems with NTP and ACPI.  So, based on that information, I further edited the grub configuration to look like this:

noapic nosmp nolapic clock=pit acpi=no

Finally, based on information regarding NTP itself and the NTP configuration parameters, I added the “burst iburst” parameters to the server lines in my ntp.conf file, like this:

server W.X.Y.Z burst iburst

This helped, as at least now NTP would synchronize against something other than the local clock (which was more than it had done previously).  For some reason, though, the /var/log/messages log file was filling up with messages about synchronizing against the local clock, then synchronizing against the server, then against the local clock, etc.  (You get the picture.)

Given that I was synchronizing against a Windows Server 2003-based computer, I thought perhaps that Microsoft’s NTP implementation was simply broken.  (This certainly wouldn’t be the first time.)  So I configured OpenNTPd on an OpenBSD server (running OpenBSD 3.8) and re-configured the CentOS server to synchronize against the OpenBSD NTP server.

<aside>OpenNTPd is ridiculously simple to configure and operate, and just works.</aside>

The repetitive synchronization messages still appeared, but were appearing with far less frequency.  And the time still isn’t synchronized to the level I would like, but it does stay within a minute or so of the rest of the network (well within the 5 minute gap required in order for Kerberos authentication to work).

So, it’s still not working as cleanly as the older Red Hat Linux 9.0-based servers, but it is working.  Given that I’m still running these servers under an old version of VMware (which, technically, doesn’t support Linux 2.6 kernels) I may try upgrading to a new version of VMware to see if that helps at all.