On 11/18/10 15:35, James Carlson wrote: > 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.
That may be coincidental. There are a lot of things that get retried every 60 or 64 seconds. This appears to be an attempt to configure a peer, based on the stack. This suggests that you have peer or server lines with hostnames on them. The fact that the attempt to configure the peer fails is interesting. If the address were not resolvable, then it would not even try. This leads me to suspect that the peer_config routine is rejecting it, and the most likely reason that I can think of is that there is no external interfaces configured. You might try replacing the hostnames with they actual addresses. That should bypass the resolver process and make the errors more visible. After you replace the hostnames, restart and then run "ntpq -p". -- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier -----------------------------------------------------------------------| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
