Managing NFS and NIS, 2nd Edition - Mike Eisler [228]
Hourly update:
52 * * * * rdate timehost > /dev/null 2>&1
Daily update:
52 1 * * * rdate timehost > /dev/null 2>&1
The redirection of the standard output and standard error forces rdate 's output to /dev/null, suppressing the normal echo of the updated time. If a cron-driven command writes to standard output or standard error, cron will mail the output to root.
To avoid swamping the timehost with dozens of simultaneous rdate requests, the previous example performs its rdate at a random offset into the hour. A common convention is to use the last octet of the machine's IP address (mod 60) as the offset into the hour, effectively scattering the rdate requests throughout each hour.
The use of rdate ensures a gross synchronization accurate to within a second or two on the network. The resolution of this approach is limited by the rdate and cron utilities, both of which are accurate to one second. This is sufficient for many activities, but finer synchronization with a higher resolution may be needed. The Network Time Protocol (NTP) provides fine-grain time synchronization and also keeps wide-area networks in lock step. NTP is outside the scope of this book.
* * *
[6] Some Unix utilities have been modified to handle small time skews in a graceful manner. For example, ls tolerates clock drifts of a few minutes and correctly displays file modification times that are slightly in the future.
[7] The hardware clock, or "hardclock" is a regular, crystal-driven timer that provides the system heartbeat. In kernel parlance, the hardclock timer interval is a "tick," a basic unit of time-slicing that governs CPU scheduling, process priority calculation, and software timers. The software time of day clock is driven by the hardclock. If the hardclock interrupts at 100 Hz, then every 100 hardclock interrupts bump the current time of day clock by one second. When a hardclock interrupt is missed, the software clock begins to lose time. If there is a hardware time of day clock available, the kernel can compensate for missed hardclock interrupts by checking the system time against the hardware time of day clock and adjusting for any drift. If there is no time of day clock, missed hardware clock interrupts translate into a tardy system clock.
Chapter 15. Debugging Network Problems
This chapter consists of case studies in network problem analysis and debugging, ranging from Ethernet addressing problems to a machine posing as an NIS server in the wrong domain. This chapter is a bridge between the formal discussion of NFS and NIS tools and their use in performance analysis and tuning. The case studies presented here walk through debugging scenarios, but they should also give you an idea of how the various tools work together.
When debugging a network problem, it's important to think about the potential cause of a problem, and then use that to start ruling out other factors. For example, if your attempts to bind to an NIS server are failing, you should know that you could try testing the network using ping, the health of ypserv processes using rpcinfo, and finally the binding itself with ypset. Working your way through the protocol layers ensures that you don't miss a low-level problem that is posing as a higher-level failure. Keeping with that advice, we'll start by looking at a network layer problem.
Duplicate ARP replies
ARP misinformation was briefly mentioned in Section 13.2.3, and this story showcases some of the baffling effects it creates. A network of two servers and ten clients suddenly began to run very slowly, with the following symptoms:
Some users attempting to start a document-processing application were waiting ten to 30 minutes for the application's window to appear, while those on well-behaved machines waited a few seconds.