[ntp:questions] ntpd sometimes goes wacko, all peers in INIT, packets mostly ignored, but restart fixes it

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Oct 3 06:47:18 UTC 2007

In article <47012ACD.6070300 at math.arizona.edu>,
aprl at math.arizona.edu (Alexander Perlis) wrote:

> Greetings. Can someone tell me what to try next to figure out the 
> following problem? We're stumped.

You haven't really provide any hard information, but a wild guess
would be misuse of local clock in an isolated time island.

To make a start, we need the contents of the ntp.conf file, and the
result of the ntpq peers command.  As you seem to be rejecting 
responses, the output of ntpq's rv command for each server association
is also likely to be useful, as it should contain the reject reason.
The tcpdump trace might also be helpful.  The system call trace isn't
really much use.

> All our servers have identical ntpd configurations. Sometimes one of 

This is not a good idea unless they all have *real* hardware reference
clocks of the same type, and even then, that is not a good idea unless
it is the same hardware clock with its output replicated, at the hardware
level (which can be useful for very tight synchronisation, at the expense
of availability), otherwise diversity in clock type and manufacturer
is desirable.

Specifying the same external servers is bad, because it means there is
no diversity and also puts an unnecessary load on the servers.

Configuring only local clock on all of them will produce all sorts of
instabilities; if there are multiple systems with local clocks, with 
or without a real source of time, there should be a clear hierarchy.
If you don't understand this, you should not use local clock at all;
it is not as necessary as people seem to think.

More information about the questions mailing list