October 13, 2004, 10:23 AM — Send in your Unix questions today!
See additional Unix tips and tricks
Last week's column introduced NTP, the Network Time Protocol and the concept of highly accurate timekeeping. While numerous commands exist to help system administrators maintain fairly accurate time on the systems they manage, the most obvious are very limited. As a result, most networks suffer from large discrepancies in system time. Time differences such as those shown below (taken from an actual network) are not uncommon:
host01: Thu Oct 14 10:50:23 EDT 2004
host02: Thu Oct 14 10:43:53 EDT 2004
host03: Thu Oct 14 10:41:52 EDT 2004
host04: Thu Oct 14 10:50:13 EDT 2004
host05: Thu Oct 14 10:33:59 EDT 2004
host06: Thu Oct 14 14:48:17 GMT 2004
host07: Thu Oct 14 10:52:04 EDT 2004 *
host08: Thu Oct 14 10:52:33 EDT 2004
host09: Thu Oct 14 10:49:55 EDT 2004
host10: Thu Oct 14 10:33:20 EDT 2004 *
host11: Thu Oct 14 10:51:22 EDT 2004
Just within these eleven sequentially polled systems, we can see a considerable variability in the reported time. While the polls took place over the span of a few seconds, the time differences are considerably larger than a few seconds. There is, in fact, a difference of 18 minutes and 44 seconds between the earliest and latest reported times. Had we polled the entire network, the gap between the earliest and latest times reported would have been even wider.
To force systems such as these into more close time proximity, the systems administrator may use any of a number of commands with varying degrees of success.
The date Command
The date command which allows the sysadmin to set the date and time is the most obvious command for correcting the time on a system, but depends on the sysadmin having a fairly accurate time reference. This command is also run one system at a time. Using the date command to bring two systems into synch, a sysadmin is unlikely to get the system times closer than within a few seconds of each other. The date command is clearly not the command of choice when synchronization is important. And, on a network with several hundred systems, this approach can be both tedious and inaccurate.
Were a systems administrator to issue a date command in a loop such as the one shown below, the system times would be closer than those shown above, but would continue to vary by as many seconds as the loop took to complete. And, of course, this time variation will be increasingly significant if a password has to be entered for each ssh command.
for host in `cat host_list`
do
ssh $host "date 10141045"
done
The date command is clearly only minimally useful in synchronizing systems. System clocks that tend to gain or lose time, even if only on the order of a couple of seconds each day, will quickly widen the time gaps again. In addition, systems configured for other time zones -- such as the one system reporting the time as GMT in the list shown above, would have their clocks thrown off by hours if we used the date command as shown.
The rdate Command
The rdate command, a far better choice for synchronizing clocks on a network, requires that a sysadmin select one system accessible to his/her network, presumably one that keeps fairly accurate time to use as a time reference for the rest.
The following loop would yield much better results than that shown above. After all, the time required for this loop to complete will have no detrimental effect since each rdate command will synch up to the time on the reference server when that command is run.
for host in `cat host_list`
do
ssh $host "rdate timekeeper"
done
In addition, the rdate command does not override the time zone on the target system. Instead of setting the time literally to a value that is provided on the command line, rdate requests time data which is independent of the time zone. In other words, if you run "rdate
The rdate command is generally run at system start-up or through cron once a day or once an hour to align clocks on systems on a LAN. Compared to the undisciplined system clocks shown earlier, this is a great improvement. However, from the point of view of each system whose clock is reset with rdate, some very unusual things can happen. Clocks can jump forward or backward in time each time the rdate command is run. This behavior can lead to some very strange interpretations of time-sensitive events.
NTP Commands
