What should the behavior of SMF be in regard to NTP? If you have it configured then I think you expect it to work. If it does not, then something needs to be done to fix it. For some users NTP is an absolute requirement. For others it is optional. And for others, they just don't care.
Once NTP V4 is integrated, we will probably have this be configurable. It is more difficult to get the desired behavior with the current program. Michael Schuster wrote: > Hi all, > > I've added smf-discuss and networking-discuss to this email thread, as I > currently think this question falls "in between". (sig.oe is on bcc). > > Brian Utterback wrote: >> See CR 6439135 for some discussion of this. This only covers >> the timeout issue, not the disable issue. > > thx. I'm not really trying to address this, rather, I'm interested why > so much else seems to depend on this: > > $ svcs -D ntp > STATE STIME FMRI > online Jun_20 svc:/milestone/multi-user:default > $ svcs -D svc:/milestone/multi-user:default > STATE STIME FMRI > disabled Jun_20 svc:/network/dhcp-server:default > disabled Jun_20 svc:/system/iscsitgt:default > disabled Jun_20 > svc:/application/management/common-agent-container-1:default > online Jun_20 svc:/system/intrd:default > online Jun_20 svc:/milestone/multi-user-server:default > online Jun_20 svc:/application/graphical-login/cde-login:default > online Jun_20 svc:/application/cde-printinfo:default > online Jun_20 svc:/system/webconsole:console > >> James Carlson wrote: >>> michael schuster writes: >>>> - if svc:/network/ntp:default is enabled, and no ntp server is >>>> available, why are the dependencies configured so that graphical >>>> login (among other services) doesn't come up? >>> >>> The service is broken in that state, and based on the way SMF works, >>> dependencies are not started if a service is broken. > > I'm aware of that, and that was not *precisely* my question :-) I'm > asking why the dependencies are what they are. > >>> Whether those things are actually "dependent" is possibly a matter for >>> debate. > > indeed. > >>>> - if I "svcadm disable ntp" while it's in "offline*" state because >>>> of the situation I describe above, why is this disabling not >>>> effective immediately, or after reboot (yes, that means after reboot >>>> I see the same situation again!). >>> >>> Not sure. > > anyone? > > it's interesting to note that although I didn't manage to disable ntp, > perceived startup time was must less when I rebooted yesterday evening > at the SVOSUG meeting. I checked the ntp service, it was again in the > "offline*" state. > > Michael -- blu Screening ideas are indeed thought up by the Office for Annoying Air Travelers and vetted through the Directorate for Confusion and Complexity - Kip Hawley, Head of the TSA ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
