[ntp:questions] all servers rejected

Richard B. Gilbert rgilbert88 at comcast.net
Thu May 17 19:49:02 UTC 2007


Marton Fabo wrote:
> Hi,
> 
> Can anyone tell me why may ntpd just silently reject all the specified
> servers, and fail to set the system clock, without even dropping a note
> to the syslog?
> 
> Actually I *don't* want to *understand* why it may think it's better for
> me not having clock sync at all than to sync to a "relatively
> unreliable" server. I just want it to do anything it can to keep sync as
> much as possible.
> 
> I'm running a FC3 in a VMWare, and its clock gains huge times a day
> (>1hr). I don't have the time or intent to track down why it behaves
> like that, I just want it to remain within reasonable bounds without
> much fiddling.
> 
> Any tips, which don't require me to dig deeper into ntpd internals and
> algorithms than I have so far?
> 
> thanks
> mortee
> 
> ntpd 4.2.0a at 1.1190-r
> 
> ntpq> as
> 
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 14884  9014   yes   yes  none    reject   reachable  1
>   2 14885  9014   yes   yes  none    reject   reachable  1
>   3 14886  9014   yes   yes  none    reject   reachable  1
>   4 14887  9014   yes   yes  none    reject   reachable  1
>   5 14888  9014   yes   yes  none    reject   reachable  1
>   6 14889  9014   yes   yes  none    reject   reachable  1
>   7 14890  9014   yes   yes  none    reject   reachable  1
> ntpq> pe
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  LOCAL(0)        ..           50 l   10   64  377    0.000    0.000   0.061
>  gerzson.home    216.165.129.244  2 u    2   64  377    2.896  -68538.
> 57390.4
>  ubul.kfki.hu    148.6.0.36       2 u    5   64  377   17.843  -68485.
> 55842.6
>  adm.active24.cz 192.53.103.108   2 u    2   64  377   36.123  -4423.5
> 57625.6
>  bus2.isp.contac 212.65.193.203   4 u    4   64  377   26.042  16366.1
> 73100.6
>  ntp1.inrim.it   .UTCI.           1 u    -   64  377    8.848  -57270.
> 50913.9
>  nostromo.textdr 132.163.4.102    2 u    1   64  377    8.418  20270.2
> 76393.4

VMWare or, at least VMWare ESX, wants to control the clock.  If the 
client operating systems are also trying to control the clock, chances 
are that nothing will work right!  If you configure VMWare to run ntpd 
things might just work a little better.




More information about the questions mailing list