Jean McCormack wrote: > Jean McCormack wrote: >> Dave Miner wrote: >>> Jean McCormack wrote: >>>> >>>> We have an interesting problem on the SMF work with respect to >>>> enabling the SMF service when commands are run. >>>> >>>> The general premise we've been working under is that if no install >>>> services are "on" then the SMF service should be in maintenance. >>> >>> "when the SMF service is enabled", of course. >>> >>>> Also, all command should cause an attempt to enable the SMF service >>>> when they are executed. >>>> >>>> Our problem: >>>> If the SMF service is enabled when running a command like >>>> create_service or enable and there are no install services "on" we >>>> go into maintenance mode and can't enable the service or create it. >>>> Chicken and the egg problem. >>>> - We want the service to go into maintenance and the command to >>>> error out if a dependency is unfulfilled. But not if if there are no >>>> "on" install services. >>> >>> I don't understand the "but not..." here. If it's enabled with no >>> install services enabled, then the general premise stated earlier >>> would seem to dictate it goes to maintenance. >>> >>>> - We don't want this behavior if we are creating/enabling the first >>>> install service. >>>> >>> >>> I don't see the problem; why can't you create the install service, >>> then enable the SMF service? > Sorry. I missed this on my last reply. Wouldn't we want to attempt to > enable the SMF service immediately? That way if > we have any dependency issues that send us into maintenance we would > know and not continue trying to create the > service.
IMO a request to create-service needs to create the service regardless. If the dependency chain isn't fulfilled, that's a subsequent action that can be acknowledged and rectified outside of the install service creation. -ethan > > If this statement is false, then we could do what you say and I believe > we have no issues. > > Jean > >>> >>>> >>>> We've come up with 2 solutions to this and would like feedback on >>>> them today. >>>> >>>> Solution 1: Put the SMF service into degrade status not maintenance >>>> if there are no install services in "on". This would not be >>>> considered an error to exit a command from and the service would be >>>> enabled if the command succeeds. >>>> >>> >>> Degraded is really not implemented in any useful way in the SMF >>> machinery at this point. I would discourage using it. >>> >>>> Solution 2: Currently the modification of the status information is >>>> at the end of the create_service/enable functions. We could move >>>> this to the beginning of the functions and create a 3rd state for >>>> status (enabling ???) to differentiate from a full enable. Obviously >>>> all error conditions that exit would need to clean up by changing >>>> the status back to off or deleting the property group. >>>> >>> >>> This doesn't seem necessary. I would think that there's the state of >>> each install service (enabled or disabled) and, separately, there's >>> the state of the SMF service. The latter governs whether any install >>> services can be used, while the former merely provides a specific >>> sub-state for each individual install service. If you create or >>> enable an install service, then either enable or clear (should you >>> find the install SMF service in maintenance) the SMF service, won't >>> you get the desired behavior? >>> >>> Dave >> I'll try to communicate this better with an example. >> >> 1)install/server:default is in maintenance. We have no install >> services enabled. >> 2)The user types installadm create-service. This is supposed to >> enable/clear install/server:default. >> 3)When we enter the installadm code we immediately try to enable/clear >> the install/server service. >> 4)We have no install services enabled yet. In fact we have no services. >> 5)install/server:default goes into maintenance. >> 6) Code exits and prints error message. >> >> Jean >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
