Shwetha Srinivasan - Sun Microsystems - Bangalore India wrote: > Hi Nicholas, > That's right, NTP will not start if there is no name service configured.
Really? Have you tested that assertion? You're adding a dependency on milestone/name-services. $ svcs -l milestone/name-services fmri svc:/milestone/name-services:default name name services milestone enabled true state online next_state none state_time Mon Feb 02 07:31:06 2009 logfile /var/svc/log/milestone-name-services:default.log restarter svc:/system/svc/restarter:default dependency optional_all/none svc:/network/dns/client (online) dependency optional_all/none svc:/network/ldap/client (disabled) dependency optional_all/none svc:/network/nis/client (disabled) dependency optional_all/none svc:/network/rpc/nisplus (disabled) It depends optionally on all name services. That should mean that if all name services are disabled, milestone/name-services will simply come online. If the name service configured goes into maintenance, milestone/name-services will come online. An optional dependency in your code on milestone/name-services, however, might make this more clear. As to Brian's questions later in the thread: > By the way, does anybody know why there would be such an > increase in this happening? Did something change in SMF > processing that would cause NTP to start earlier than it > did before? After a quick scan, I don't see a detailed analysis of the race (what command is being raced with in the configurations your customers are running with) so I can't hypothesize about any specific causes, but since startup is parallel now, an addition or removal of a service or dependency on the system (or simply most customers running on faster machines) can perturb the startup order to reveal bugs. Services need dependencies on the things on which they depend, which this seems to be a case of. As to another fix suggestion... if the daemon needs to work in both conditions, and be started before name resolution is available, retrying lookups in the daemon is about the only suggestion I have right now. I don't have a good proposal for another fix -- if a modern version of NTP would do retries internally, as Ceri originally suggested, it seems like another good reason to move forward with that work. I've personally been hopeful for an upgrade for a while, but that's unrelated to this issue. liane
