Brian Utterback wrote:
> On 11/18/10 10:14, Brian Utterback wrote:
>> On 11/18/10 09:12, James Carlson wrote:
>>> I'm getting messages like this:
>>>
>>> Nov 18 09:01:17 carlson ntpd_intres[1004]: [ID 702911 daemon.error] ntpd
>>> indicates no data available!
>>>
>>> They seem to be generated once every minute. As far as I can tell, NTP
>>> is working fine and ntpq shows that it's in sync, but the daemon whines
>>> anyway. The only "special" thing I have (in an otherwise ordinary
>>> client configuration) is a directive to broadcast on an internal network.
>>>
>>> Does anyone know what this message might mean?
>>>
>> I'll look at what the specific message is, but right away I can give
>> you an idea. Notice that it isn't really the ntpd daemon, it is
>> ntpd_intres, which is NTP's resolver. The ntpd daemon does not call
>> getaddrinfo or other name service calls directly because they can
>> block and the daemon is single threaded. So to do name resolution
>> asynchronously, it forks a child. So, my guess is that there is
>> something going on with the hostname lookups. Do you have anything in
>> your ntp.conf file that won't resolve?
Yes, I have the broadcast address for one of my internal (RFC 1918)
networks. The system that this is running on has direct access to the
Internet, and I want it to broadcast time to my internal systems so that
I don't have to futz too much with them. (If there's an easier way to
do this, I'm all ears.)
The unusual configuration bits I've got are these:
broadcast 192.168.254.255
restrict default noquery nomodify
restrict 192.168.254.0 mask 255.255.255.0 nomodify notrust
restrict 127.0.0.1
That 192.168.254.255 address is the broadcast address on one of my local
interfaces. I don't have a DNS entry for it. It's never been my
practice before to provide names for non-host addresses, but I can
certainly do that if it'll help.
The interval on the log messages (one minute apart) seems to match the
interval of the broadcast messages, so it does look like these are related.
> Ok, it is a little more complex than I thought. The particular error
> is not a problem with the resolver, it is a problem in ntpd after all.
> Basically, the resolver process is sending back the data it resolved,
> but the ntpd is returning an error. And this error is a bit of a catch
> all, returned in a bunch of different places.
>
> Try running this script with the pid of the parent ntpd:
>
> #!/usr/sbin/dtrace -s
> pid$1::req_ack:entry
> { ustack(); }
>
> What function is calling req_ack?
CPU ID FUNCTION:NAME
0 73334 req_ack:entry
ntpd`req_ack
ntpd`do_conf+0x2d6
ntpd`process_private+0x5c2
ntpd`receive+0x1324
ntpd`ntpdmain+0x4c7
ntpd`_start+0x7d
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
