[ntp:questions] nptq -p slowness

Ronan Flood usenet at umbral.org.uk
Mon Jan 29 18:28:59 UTC 2007


Harlan Stenn <stenn at ntp.isc.org> wrote:

> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
> 
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
> 
> I want to stop doing this resolution altogether, but the last time I asked
> Dave about this he said he wanted to keep the lookup in place, even though
> it is only useful for IPv4.

I've just tried a test with ntpq 4.2.4 and I do not see this behaviour
of looking up the refid in the DNS for ntpq -p, or ntpq -np.  ntpq -p
does show lookups for the PTRs of the server IPv4 addresses in my host
config and A lookups for the corresponding names.  However I'm running
ntpd 4.2.2 not 4.2.4, so could the refid lookups be in ntpd?

As I read the code of ntpq, the refid string is passed to decodenetnum()
to check if it is a valid IP address, which in turn calls getaddrinfo()
with hints flag AI_NUMERICHOST.  On Solaris the man page for that says

     If the AI_NUMERICHOST bit is set in the ai_flags  member  of
     the hints structure, then a non-null nodename string must be
     a numeric  host  address  string.   Otherwise  an  error  of
     EAI_NONAME is returned.  This flag prevents any type of name
     resolution service (such as DNS) from being called.

I don't think the original poster said what OS he's using, but perhaps
there is a difference here?

-- 
Ronan Flood <usenet at umbral.org.uk>




More information about the questions mailing list