Redhat 7.3 NTP/NTPD problems

The Network Time Protocol is a method for a computer to obtain the correct time over the network, and keep its clock running at a high degree of accuracy. Incorrect times will lead to widespread problems with mail, nfs, make, backup scripts, etc. The hardware and software clocks in inexpensive PC computers often drift far afield, and in any case it is a nuisance to set the CMOS clock. An open source program - ntpd - is used in most computer systems to implement the protocol, and ntpd is included with Redhat 7.3, but not turned on by default. This leaves Linux with only the CMOS clock and the CPU timer for timekeeping.

A simple client installation of ntpd is indeed very simple - a binary daemon (ntpd) periodically connects to a time server at port 123 and updates the system clock. The daemon rarely needs more than one argument, and the configuration file need not be more than two lines. Nevertheless, any newcomer is likely to be confused by the fact that (1) in spite of the elaborate ntpd.conf file supplied, the Redhat ntp daemon won't be working after a default install and (2) the hundreds of pages of documentation for ntpd are strictly for advanced cronologists.

Redhat 7.3 comes with a complete set of ntpd binaries but they are not enabled at boot time. There is a script in /etc/init.d to control ntpd, but if run, ntpd does not run correctly. The problems seem to be entirely in the script and configuration file.

Fatal Problems

  1. /etc/init.d/ntpd reads a list of arguments for ntpd from the file /etc/sysconfig/ntpd when starting ntpd. By Redhat default the arguments are "-U ntp". These arguments are not documented in the ntpd man page or on the man pages at, but is mentioned in /usr/share/doc/ntp-4.1.1/ntpd.htm:

    The apparent effect of this is to make ntpd run as user ntp. But user ntp (with UID=38) is not root, and thus no has ability to update the OS clock. It does apparently bind to the time port before giving up root. It is very difficult to understand how this situation could persist, but even after several months it is not mentioned on the RH website and "up2date" does not bring a correction. A few people have mentioned it in newsgroups.

    In a private communication, Mony Walls has written to me that the ntp daemon can still set the time as user ntp, because it can switch back to root for that purpose alone. Perhaps this is true, but without an inaccurate clock, I don't see any way to test this.

  2. The Redhat installation program never prompts for the address of an actual ntp server, nor does it do any searching on its own. Rather it specifies for the ntp server in the default /etc/ntp.conf file. I can't imagine what this accomplishes, as that merely points to localhost.

Minor Problems

  1. Man pages are not installed by default.

  2. The script uses the deprecated "ntpdate" command at startup, rather than the endorsed "ntpd -q" command.

  3. There are no installation instuctions. This quick start page is helpful but not Redhat specific and says nothing about choice of command line arguments or basic testing.

  4. A couple of bits of information that will reduce frustration for newbies are that ntptrace (the command to run for ntp status information) won't start working for about an hour after the daemon runs, and that error messages go to /var/log/messages.

Suggested Remedy

It is not necessary to reinstall ntpd. All you need to do is delete the /etc/sysconfig/ntpd file and modify the server line of /etc/ntp.conf to point to a real server. Run /etc/init.d/ntpd from your /etc/rc.local. An hour later, try "ntptrace". That command will show you the path from your clock to a "Stratum 1" time server, probably an atomic clock at the National Bureau of Standards, but possibly elsewhere.

If your LAN doesn't already have one your ISP probably has an ntp server. If they don't document the address, try host "ntp" in their domain or their major routers and nameservers before resorting to public servers. All Cisco routers can serve ntp, but it may not be turned on. I think more ISPs would have a time server than would think to tell you about it - poke around.

I did receive this letter from an informed source:

Date: Sun, 8 Sep 2002 20:45:21 -0700 (PDT) From: Matt Perry <matt at primefactor dot com> To: Daniel Feenberg <feenberg at nber dot org> Subject: RedHat NTP details On Fri, 6 Sep 2002, Daniel Feenberg wrote: > You did see that someone wrote to me and pointed out that in spite of > the note in the user docs, -u does not really run ntpd as non-root... Well, sort of. Redhat's ntpd requires the use of libcap which is a set of userspace utilities for an implementation of POSIX draft 1003.1e. Note that this is libcap as in "capabilities" not libpcap which is for "packet capture." This draft used to be called "POSIX capabilities." What it does is allow for programs that are non-root to have specific capabilites that root would have. Rather than give a program all root privilges, you can define certain functions that would require root privileges and assign them to the program. A process has three sets of bitmaps called the inheritable (I), permitted (P), and effective (E) capabilities. Each capability is implemented as a bit in each of these bitmaps which is either set or unset. When a process tries to do a privileged operation, the operating system will check the appropriate bit in the effective set of the process (instead of checking whether the effective uid of the process is 0 as is normally done). You can use the utilities that come with the libcap library to look at the capabilities of a running process. On my system I have ntpd running with a PID of 806: # ps axfu |grep ntp ntp 806 0.0 0.7 1904 1896 ? SL Aug24 0:03 ntpd -U ntp So I can use the getpcaps command to see what capabilities ntpd has: # getpcaps 806 Capabilities for `806': = cap_sys_time+eip So it has the cap_sys_time capability for the inheritable, permitted, and effective bits. This is what allows ntpd to run as a non-privleged user and still make a single privleged function call. So your next question is probably "Why isn't this in the docs on the NTP site?" That's because this is a Red Hat patch. If you install the ntp source RPM and cd to /usr/src/redhat/SOURCES you'll see the patch along with three others. Regarding configuration: Just like dhcpd doesn't work out of the box, ntpd isn't going to either. How you configure it depends on your network and how you handle time services. Also, if Red Hat just included a default time server in the config file, all those people who run ntpd would cause a denial of service against that one poor server. The latest Red Hat beta prompts to set an NTP server the first time X11 comes up, but you'll still need to set one by hand when running without X just like on current versions of Red Hat. Where I work, we have one machine as a master NTP server which has seven public NTP servers defined. All of our other machines, both servers and workstations (almost 500 in total) point to this one internal NTP server for synchronization. Actually, I have NTP configured to make time available via multicast and all of the other machines are set to receive via the multicast IP to keep network traffic down. Anyway, to configure NTP in its most basic form, all you need to do is install the RPM, and then add a line like the following to /etc/ntp.conf: server That's it. You can add more server lines if you want. I add at least two to my ntp.conf file, sometimes more like the server at work. When ntpd can't get a response from one, it'll move on to the next one. Do not remove the one that points back to You said in your article that you don't know what this is used for, but it's explained right in the comments above that line. It, along with the following "fudge" command, creates a fake driver for use when there is no other source of time. This will help the machine keep reasonably acurate time when an outside time source can't be reached. This page explains in more detail: As for the other issues you mentioned: 1. There are no man pages because the original NTP distribution doesn't contain any. 2. While ntpdate may be deprecated, it's still included in the current distribution and as such, it's probably not a problem to use it. There's really not any difference between ntpdate and 'ntpd -q' except for the fact that ntpdate is just a separate program. I'm sure that once the NTP distribution removes ntpdate altogether that Red Hat will update their script. The init script only calls ntpdate if you have populated /etc/ntp/step-tickers with the name of a time server. If that file doesn't exist or is blank then ntpdate isn't called. Instead, at least on RH 7.3, ntpd is started with the -g option which allows it to make time adjustments greater than 1000 seconds. By default, ntpd will exit with an error in the syslog if the time is off by greater than 1000s. I find this option preferable to the ntpdate option and the 'ntpd -q' option because both of those will wait and not return until they have either timed out or set the time. In contrast, starting ntpd with the -g option will go ahead and daemonize the process so that the system can continue booting while ntpd is dealing with getting and setting the time. As for your suggested remedy, I would advise against removing /etc/sysconfig/ntpd entirely. Granted this is a sysadmin style so you might admin your machines differently. However, if you wanted to run ntpd as root, it would be better to edit /etc/sysconfig/ntpd to set OPTIONS="" so that the existance of the file and the fact that you can add options there is somewhat documented. One other thing to note is that the time is update slowly. Rather than just setting the date to the correct time, it slowly adjusts the time to correct it. This helps from skewing the time on log files and such. It's also why if you set your time wrong and run ntpd, it looks like it's not working. The rate of correction is the clock is adjusted by 1 second every minute. Date: Tue, 06 Jan 2004 17:03:43 +0000 From: Martin Beecroft <martin at beecroft dot co dot uk> To: feenberg at nber dot org Subject: NTP Hi Daniel, I have been struggling with ntp on redhat servers, and have found your page at very useful. However, to get my clocks syncing correctly I had to perform one extra step which I did not see listed anywhere. At the top of /etc/ntp.conf, there is a line which reads: restrict default ignore None of my servers would sync correctly, until I commented this line out. As matt@primefactor pointed out, the config files would need to be changed from the default, but I would have thought that this line would have been commented out by default, as it seems to be fairly crucial to making NTP work. Anyway, thanks for the ntp page as it has proved to be very useful in my quest. Cheers Martin Beecroft

An updated version of this page will be kept at


Daniel Feenberg
feenberg at
5 September 2002