[collectd] ntpd plugin complaining

[Luboš Staněk]

Hi,
the ntpd plugin would get system settings and do not evaluate IPV6
structures when IPV6 is not available.


Florian Forster napsal(a):
> On Fri, Oct 27, 2006 at 03:09:25PM +0200, Lubo?? Stan??k wrote:
>>> That'd be my fault, I'm afraid.. Why's that error occuring in your case?
>>> AF_INET6 should be supported by pretty much all operating systems now -
>>> even that evil one ;)
> 
>> Everything I cannot handle is evil. :)
> 
> I smell yet another proof for the evilness of women.. *smirk*
> 

Women are the light exception to this rule. You cannot handle anything
so instinctual. :)
But to return to the subject, none of the authors of the ntpd server is
a woman. Is there the name Florian used for men also? :)


>> 1) The system is configured for only IPV4, module ipv6 is disabled.
>> /etc/modprobe.conf - alias net-pf-10 off
>> /ets/sysconfig/network-scripts/ifcfg-<interface> - IPV6INIT=no
>> Module ipv6 is not loaded.
>> ntpd does not listen on ::#123.
>> Every 10 seconds collectd[*]: ntpd plugin: getnameinfo failed: ai_family
>> not supported.
> 
> That is surprising, because `getnameinfo' is only ever called if one of
> ntpd's peers has the `v6_flag' set. However, no explicit address family
> is passed to `getnameinfo', but it examines the `struct sockaddr', which
> is provided by the NTP-daemon.
> 

The ntpd is compiled on RedHat build farm. The --enable-ipv6 was not set
but the build system autoconfigures IPV6 support even on the evil system:
checking for IPv6 structures... yes
checking for Kame IPv6 support... no
checking for struct if_laddrconf... no
checking for struct if_laddrreq... no
checking for struct sockaddr_in6.sin6_scope_id... yes
checking for in6_pktinfo... yes
checking for in6addr_any... yes


>> Oct 27 14:56:03 ls collectd[23815]: rrd_update failed:
>>   ntpd/time_offset-0.0.0.0.rrd: illegal attempt to update using time
>>   1161953762 when last update time is 1161953762 (minimum one second
>>   step)
> 
> The problem here appears to be, that the peer could not be resolved. At
> least it's not normal, that the IP-address 0.0.0.0 is being used.
> 
> All in all I have the suspicion that your ntpd is returning funky data.
> Could you tell me which version you're using and if the following
> command works:
>   ntpdc -c peers localhost
> 
> Regards,
> -octo


Oct 29 15:40:04 ls collectd[8096]: rrd_update failed:
ntpd/time_offset-0.0.0.0.rrd: illegal attempt to update using time
1162132804 when last update time is 1162132804 (minimum one second step)

I have found that these messages were not so frequent and were caused by
the impossible or slow or anything with connection to the target. I am
discovering the reason. You can see many outlyers in the pe listing
which is the issue.
So you can ignore it.


But there is nothing more wrong about ntpd running on the machine.

Well, here is the funky ntpd report (I used ntpq for more info instead
of ntpdc although it works too):

The system works with firewall, all peers are enabled to go through.

ntpd version - the system id Fedora Core 5:
ntpd 4.2.0a at 1.1196-r Thu May 11 09:19:35 EDT 2006 (1)

# ntpq> pe
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
-img7.imagepile. 67.128.71.76     2 u    1   64  377  214.592   38.832
 5.761
-cynicbytrade.co 81.62.248.156    4 u   19   64  337  218.971   34.624
15.952
+banana.irc.gr   192.36.134.25    2 u   10   64  377  110.058   51.730
 5.919
+kamelot2.dkm.cz 195.113.144.201  2 u   14   64  377    4.774   52.100
 7.182
*tik.cesnet.cz   .GPS.            1 u    -   64  377    6.037   50.075
16.002
-swisstime.ee.et 129.132.2.22     2 u    -   64  173   35.713   37.714
18.165
+ntps1-0.cs.tu-b .PPS.            1 u   60   64  377   44.967   58.329
 9.593
 LOCAL(0)        LOCAL(0)        10 l    8   64  377    0.000    0.000
 0.002

# ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 62341  9314   yes   yes  none   outlyer   reachable  1
  2 62342  9314   yes   yes  none   outlyer   reachable  1
  3 62343  9414   yes   yes  none  candidat   reachable  1
  4 62344  9414   yes   yes  none  candidat   reachable  1
  5 62345  9614   yes   yes  none  sys.peer   reachable  1
  6 62346  9314   yes   yes  none   outlyer   reachable  1
  7 62347  9414   yes   yes  none  candidat   reachable  1
  8 62348  9014   yes   yes  none    reject   reachable  1

# ntptrace
localhost.localdomain: stratum 2, offset -0.001789, synch distance 0.030752
tik.cesnet.cz: stratum 1, offset 0.000061, synch distance 0.001557,
refid 'GPS'

And, of course the latest ntpd plugin report:

Oct 29 15:39:54 ls collectd[8096]: ntpd plugin: getnameinfo failed:
ai_family not supported
Oct 29 15:40:04 ls collectd[8096]: ntpd plugin: getnameinfo failed:
ai_family not supported
Oct 29 15:40:04 ls collectd[8096]: ntpd plugin: getnameinfo failed:
ai_family not supported
Oct 29 15:40:04 ls collectd[8096]: ntpd plugin: getnameinfo failed:
ai_family not supported
and so on...

Best regards,
Lubos