In article <[EMAIL PROTECTED]>, Richard B. Gilbert <[EMAIL PROTECTED]> wrote:
> This just what happened. Both servers seem to have been serving their > unsynchronized local clocks. The servers diverged and the client had no >From what he said, I think that they *were* configured with a real server as well, but that, at least one, real server was given a wrong address, and maybe the stratum of the local clock reference wasn't set to 10 or so. One of the points that I keep making is that configuring a local clock is something that should only be done after considerable thought, because, amongst other things, it prevents downstream ntpd's detecting that the server in question is hopelessly unsynchronised. Unfortunately, most distributors seem to be enamoured with the idea and configure it in by default. If the servers in question had not had a local clock configured, and had a bad real reference configured, they would either never claimed to be valid sources, or would have been detected as such within about a day of losing their good server. If time is important to the application, it could have used the ntp_adjtime system call, or local equivalent, to detect whether there was a validly synchronised time, and alarmed at that point. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
