Synchronizing Time

If you are running distributed applications, the time on the various systems may be critical. When using networked filesystems (such as NFS), you will have problems if the time on the client is not close to the time on the server (some files will have access and modification times in the future when they are written by a system with a clock set in the future, causing problems with applications that rely on these timestamps to make decisions). Other network protocols such as NIS+ also depend on relatively synchronized system clocks.

Setting the Time Zone
The first thing you must do is make sure the time zone on your systems is correct. The time zone is important because time synchronization usually uses Coordinated Universal Time (UTC), which is not the time you are used to seeing on your system. How you set the time zone is, unfortunately, completely system dependent. Here are some pointers for some popular systems:

Red Hat Linux: /etc/sysconfig/clock (or run timeconfig)

Debian GNU/Linux: /etc/timezone

Solaris: /etc/TIMEZONE (symbolic link to /etc/default/init)

AIX: /etc/environment and /etc/profile

FreeBSD: /etc/localtime

HP-UX: /etc/TIMEZONE

Tru64: /etc/svid3_tz (or run timezone)

Synchronizing Your Clocks
On most systems, you have two ways to synchronize time. One involves using the rdate or ntpdate commands to synchronize your clocks on a regular basis (hourly or daily from a cron job). The other option involves running a Network Time Protocol (NTP) time daemon (called xntpd on some systems and ntpd on others).

The rdate Command
Most UNIX variants come with the rdate command. This command can quickly synchronize a system's clock to a well-known timeserver using the RFC 868 protocol. Here is an example on a Linux system:

% rdate -s time.nist.gov

Although used in this example, the -s switch is not standard and should not be used on most systems (on Solaris, for example, the command rdate time.nist.gov would accomplish the same task). The server specified here (time.nist.gov) is run by the National Institute of Standards and Technology (NIST) Laboratories in Boulder, Colorado. You can find plenty of other public timeservers using some quick web searches.

You can set up your own server easily since most versions of inetd internally support this protocol. The protocol is not very accurate (i.e., the times might be off by a few milliseconds), but it is more than suitable for most situations. You would need to run this command from cron on a regular basis (usually at least once per day, or even hourly).

Using the Network Time Protocol
NTP has gone though several revisions and has several associated Request For Comments (RFCs are published Internet standards documents). It provides very accurate system time updates (to the millisecond). NTP is usually used with a daemon that continuously updates the system clock and may also provide services to other clients. The software is included by default on many systems and can be installed on most others.

If you like the simplicity of the rdate command but would rather use NTP, you can simply pick an appropriate server and use the ntpdate the same way you use rdate as mentioned in the previous section. This is the easiest, but least accurate and efficient, method of using NTP on a system.

The NTP software suite allows for much more advanced uses that are beyond the scope of this book. The daemon (either ntpd or xntpd) can determine the time from a variety of sources including one or more remote systems or a local device such as a GPS. The same daemon can allow other clients to synchronize their clocks from the system. It also continuously monitors any time drift present in the internal clock, and then regularly updates the clock, accounting for known drift, even if time servers are not currently available. This also reduces the chance of the system clock having sudden significant jumps in time. Quite a bit of information about the NTP protocol can be found at http://www.ntp.org.

One thing to keep in mind—NTP will not update the system clock unless it is pretty close to the server's time. For this reason, you should use rdate or ntpdate to get the time pretty close first, and then start your NTP daemon. You might want to perform this rdate every time the system boots to make sure it starts out with a fairly accurate value.

Updating the Hardware Clock
On some systems (such as x86-based systems running Linux), an updated time within the operating system kernel only lasts until the next reboot. On these types of systems, you should set your hardware clock whenever you set the time. Alternatively, setting the hardware clock once per day from cron would be adequate. Implementing one of these methods prevents the system from booting with the incorrect time.

I can't profess to know the details of all hardware platforms and operating systems. The only system I have personally experienced this on is x86-based Linux. On these systems, the command /sbin/hwclock –systohc synchronizes the date as it is stored in the kernel into the hardware BIOS.

Alternatively, you could execute your time synchronization command during system startup as well as on a regular basis so that your system always starts with the correct time.