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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine