[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