[ntp:questions] Troubleshooting who's at fault
David Woolley
david at ex.djwhome.demon.co.uk.invalid
Thu Jun 25 07:08:41 UTC 2009
Ronaldo Mexico wrote:
> For some reason, the ntpd daemon on RHEL refuses to sync with the
Red Hat use the Reference implementation, at least as far as the core
code is concerned.
> [root at screamer-dc1 init.d]# ntpq -p
> remote refid st t when poll reach delay
> offset jitter
> ==============================================================================
> LOCAL(0) .LOCL. 10 l 1 64 1 0.000
> 0.000 0.001
> ntp 73.78.73.84 2 u - 16 1 0.765
> 0.013 0.001
This is pretty much a worst case configuration. Drop the local clock,
or add enough real servers to outvote it. However, I don't think that
would produce a reject status. There is an aberration in most ntpd
based packages that they contain a local clock pseudo clock driver, when
this should be an opt in for people who understand the tradeoffs. It
should never be configured on a leaf node, as it serves no purpose
except confusion.
> 2 62826 9014 yes yes none reject reachable 1
rv 62826
will tell you why it is being rejected. However, when you said various
Windows systems worked, did you mean ntpd on Windows or w32time. By
default, and in some cases, without choice, w32time will synchronise to
servers that are broken in a Windowsy way, or which having been running
unsynchronised for too long for the real protocol to tolerate them.
More information about the questions
mailing list