[ntp:questions] Re: Servers just doen't work (after following the troubleshooting page)

Per Hedeland per at hedeland.org
Thu Sep 29 06:19:06 UTC 2005


In article <433B5BE9.9050702 at ntp.isc.org> mayer at ntp.isc.org (Danny
Mayer) writes:
>Per Hedeland wrote:
>> 
>> Well, if you've not munged the output *selectively* here, I believe it
>> shows that you've run into the bug that Danny mentioned recently: The
>> client sends a query to ntp2.<mydomain>, but gets the response from
>> server2.<mydomain>, i.e. presumably a different IP address on the same
>> host. The client will not (and should not) be interested in responses
>> coming from what it sees as "someone else". The same effect will apply
>> to the intra-server/peer queries.
>> 
>
>No, that's not it at all.

I guess maybe you hadn't read the whole thread when writing this, since
it's pretty much confirmed that this is precisely what it is.

> If ntpq -p is showing the two servers listed
>(there should always be more than two, BTW) then it's receiving packets
>from those servers.

Hm? Yes, ntpq -p is showing two servers - from the original post:

[root at client1 /]# ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  ntp2.<mydomain> 0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
  ntp1.<mydomain> 0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00

How do you infer from this that it's receiving packets, to me it says
exactly the opposite? Are you saying that the current code will not show
servers that are configured but from which no packets have been
received? That would not be an improvement I think. At least as of
4.2.0, the refid in this case is shown as .INIT., but otherwise the
output is identical to the above (and present).

> The fact that they are both showing stratum 16 on
>the scoreboard indicates that neither are able to serve a valid time
>because they themselves are not synchronized.

Or, at least "traditionally", that no packets have been received from
them.

--Per Hedeland
per at hedeland.org




More information about the questions mailing list