Using the Network Time Protocol in Linux
Cris Perdue for Open Source Consulting
Introduction
Configuration
Firewalls
Monitoring and Troubleshooting
Carefully Adjusting Your Clock
Resources
Except for discussion of iptables/ipchains firewalling, this
discussion applies to Unix systems in general as well as Linux in
particular. I have worked with ntpd, also known as xntpd, versions
4.1 and 4.2, using Red Hat 7.3, 9.0 and SuSE 9.1.
The documentation for NTP is voluminous and much of it is devoted to
complex issues that may concern an expert setting up groups of time
servers for other systems to access. Practical information for the
average system administrator can be hard to extract from all of this,
so a short focused article aimed at practical setup issues seemed like
it would be valuable. The material here reflects some of the author's
personal experiences in setting up ntpd on various Linux systems and can
hopefully serve as a practical "NTP HOWTO".
This article is probably most useful for someone with system
administration experience. The setup steps are relatively simple, but
it may be hard to resolve a problem without some background. It is
aimed at managers of one or a few Linux systems who want to keep their
system clocks close enough to correct time for most practical
purposes. This does not attempt to help you set up a time server that
other systems can synchronize to; only with setting up NTP clients.
Feedback or new information are welcomed by the author.
Even on modern Linux systems, a little NTP client setup is needed.
In my experience this little setup does not always go right, so I try to help
you do a little bit of debugging. The minimum system configuration is a couple
of lines in your ntp configuration file, typically /etc/ntp.conf. You will need
a line or two or three like this:
server some.timeserver.com
server othertime.server.org
Synchronizing with more than one NTP server gives you redundancy in case
of server or network problems, and it may improve the accuracy of your
time synchronization. IP addresses are also accepted, but I prefer
hostnames, since the IP address of a server may change from time to
time.
Note: The version of ntpd released with Red Hat 7.3 (4.1.1)
could not handle hostnames in the configuration, only IP addresses.
The server would send requests and the remote servers would respond,
but the local server would ignore the responses. For older versions of
ntpd you may need to use IP addresses instead of names.
First you will need to select an NTP server or two. The
implementors of NTP itself provide a very useful list of public
NTP servers. You might also wish to try pool.ntp.org, which provides access
to a number of different time servers all answering to the same
hostname.
Before you synchronize with a time server you will want to check how
close your system clock is to the correct time and whether it is ahead
or behind the correct time. If your clock is within a minute or two of
the correct time you may be happy with the standard simple procedure.
If your clock is behind the correct time you are probably still OK, but
be aware that your clock may jump forward some time within the first
hour after you start your local time server. If your clock is ahead,
starting the time server may make your system time jump backward while
the system is running. This can have effects like making copies of
files look older than the original, and can confuse your system in a
number of ways. This tends to affect services that deal with data
modification times: database servers, network file systems, distributed
file synchronization, some cryptographic protocols, etc.. See Carefully Adjusting Your Clock for a procedure to
set your clock back carefully.
The Red Hat and SuSE Linux distributions (and most others) come with
scripts to start and stop an NTP client, which runs on your system as a
service even if it does not accept requests. When you have configured
a couple of NTP servers into your NTP config file, locate your system's
start/stop scripts, for example /etc/init.d/, and make sure your NTP
daemon is freshly started. The start/stop script might be named ntpd
or xntpd, and it normally starts at system startup. On systems such as
RedHat or SuSE, the command looks something like:
# /etc/init.d/ntpd restart
. . . or
# /etc/init.d/xntpd restart
You can start using the "ntpq -p" command within a couple of minutes
to monitor your time server and its communication with the remote
servers, and do check the system log for messages from ntpd. For more
information on these see Monitroing and
Troubleshooting below. Note that if the difference between your
system's clock and the remote server is more than 128ms you should
expect your local ntpd to step your clock forward once it is satisfied
it knows the appropriate adjustment. After a half hour or so your
system should synchronize with your remote servers and the "date"
command should give a very accurate time of day. Once you see your
time has been synchronized, use a graphical service manager tool or a
command-line tool (run as root) such as chkconfig to make your system
start ntpd at system boot time.
Your system should now stay synchronized with your time server(s)
indefinitely into the future, and should stay synchronized across
shutdowns. Your system will also keep your system BIOS clock adjusted,
so unless its battery is dead it will probably be very close to the
correct time even before ntpd starts up again. Check your system's time
again in a day or so to confirm that things are working properly for
you.
NTP is built on the UDP protocol rather than TCP. Though these are
both part of the Internet Protocol family, UDP raises different issues
with firewalls compared with TCP. Most home and small office firewalls
will allow NTP to work without special configuration, but if you are
behind any kind of firewall, you may want to do some checking in about
an hour from startup rather than waiting to see if your system clock
stays synchronized. See the Monitoring and
Troubleshooting section.
Linux kernel-level firewalling can also interfere with your clock
synchronization. A typical problem is that your system's kernel
firewall rejects incoming NTP packets. A simple measure to avoid this
is to make sure UDP port 123 is open for incoming packets from your
selected time servers. If you are using ipchains, a command to allow
NTP packets from one of your time servers looks something like this:
# /sbin/ipchains -A input --proto udp -s onetime.server.com ntp --jump ACCEPT
Iptables supports a similar command, but it is a more intelligent
facility and probably also supports more
sophisticated approaches. Any information on this would be appreciated.
ntpq -p
A most useful command for querying any time server's status is "ntpq
-p". You can query a remote time server for the same kind of
information with "ntpq -p <hostname>".
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 22 64 377 0.000 0.000 0.001
*poolxxx.ntp.org .CDMA. 2 u 118 256 377 21.631 -0.401 0.544
+tick.somnet.net 132.249.20.88 2 u 102 256 377 35.372 -0.264 9.730
The first position in the output lines is a quick indicator of the
status of the remote server. A "*" indicates the server to which you
are currently synchronized. It may take some part of an hour before
your server considers itself synchronized. A "+" is a candidate to take
the leading role if the current server becomes unsuitable for some
reason.
The labeled columns for this are:
- remote
- The IP address or DNS name of the remote server
- refid
- An identification of the type of the reference clock.
- st
- The "stratum" or level of the server: for almost all
systems, 2 is great. Your local system will have a higher number.
- t
- The type of service. Your setup will show "l" for local on your
local system, or "u" for "unicast" for communicating with remote
servers.
- when
- This is the number of seconds since the server was last heard from.
After a couple of minutes of operation your server should start to
report numeric values here.
- poll
- Current polling interval in seconds. When remote servers are
responding, "when" should be no greater than "poll".
- reach
- This and the remaining fields are important indicators of the health
of your local server, your remote servers, and their communication.
This field is really a bit array indicating whether responses have been
received to your local server's eight most recent requests. The value starts
at 0. If your local server is receiving responses to all its requests,
it will go to 1, then 3, then 7. The display is in octal, so 377 is the
maximum value. Anything less indicates that either your local server
recently started or some requests did not receive responses.
- delay
- Recent average roundtrip time in milliseconds from request to response.
- offset
- Estimated differential between your system clock and this time
server's clock, in milliseconds. You may consider this the "bottom
line" on the accuracy of your system clock. NTP can usually drive this
down to the level of the jitter or less. If your clock gets ahead or
behind by more than
- jitter
- A measure of the variability of the delays between request and
receipt of a response, in milliseconds. High jitter tends to limit
your server's ability to synchronize accurately.
tcpdump
You can easily check if packets are going out from your system and
coming back to your box using tcpdump. NTP uses port 123, so you might
issue a command like this as root:
# tcpdump udp port 123
Allow it to monitor traffic for up to an hour. You should see packets
going out to your time servers port 123 (ntp) and replies coming back
from each of them. Your local UDP port will probably also be number
123. Kernel firewalling (ipchains or iptables) can prevent
synchronization from working even if the servers are replying to your
system's requests.
If you see packets coming in from the remote time servers, but ntpq
indicates your server is not seeing them, then be sure to look at your
ipchains/iptables configuration and to consider the ntpd 4.1.1 issue
noted in the configuration section for Red Hat 7.3 and to check the
system log for configuration messages from ntpd.
syslog
Your ntpd will log various events through your system's syslog facility.
This typically means the messages will show up in /var/log/messages, in
lines containing the string "ntpd". Configuration problems are reported
here. If your local server steps the time ahead or back suddenly, it
will report that here also with a message such as: time reset
-6.394626 s.
This procedure is especially useful if your system clock is ahead of
the actual time. You can use it to prevent ntpd from making large
sudden adjustments to your system clock while the system is running,
and to make sure the system clock never jumps backward in time. The
NTP FAQ suggests doing the following steps if you can take your server
down for a little while:
- Shutdown;
- Set the BIOS clock;
- Restart.
For systems with clocks ahead of real time, plan to leave the system
off until real time catches up with its internal time when it was shut
down. Since the system clock is initialized from the BIOS clock, this
prevents the system clock from jumping back while your system is
running. Recall that Linux can be configured to interpret the BIOS
time as either local time or GMT (UTC). You can infer the
configuration by comparing output from the "date" command with the BIOS
clock time.
|
