Quoth Michael Schuster on Fri, Aug 24, 2007 at 08:18:45AM -0700: > 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
That's probably because ntp was started in rc2.d prior to SMF. When such services are adapted to SMF, they are supposed to arrange the milestone dependencies to retain past timing behavior. > > 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. Well if the service failed into maintenance, then the multi-user dependency could be made optional, and the rest of the services would start up. If the service hangs out in offline*, then SMF won't do anything. > >>> - 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!). As Renaud pointed out, svc.startd ignores requests while services are in transition. This is sort-of a bug. The disable should take effect after reboot, though, so if it doesn't then there may be a bug. David
