Nicolas Williams writes: > On Thu, Aug 03, 2006 at 10:47:17AM -0700, Alan Maguire wrote:
> > One additional detail: initially we thought that simply modeling the > > global flags as services and having routing daemons depend on these > > would be sufficient to ensure that global routing/forwarding settings > > control routing daemon execution appropriately, however it was pointed > > out that this would result in daemon services being offline if their > > dependencies are disabled. Being offline in these circumstances is > > suggestive of configuration errors where there are none it seems, so > > we modified the design slightly to accomodate this (when the ipv4(6)-routin > g > > service is disabled now, it disables the enabled routing daemon services, > > noting them so they will be reenabled if/when ipv4(6)-routing is enabled > > again). > > I think this may be a matter of improving the SMF UIs. SMF should > distinguish a service is "enabled but offline due to administratively > disabled required_all dependencies" from a service that is "enabled but > offline due required_all dependencies in maintenance state." SMF operates on the principle that enabled services that aren't running are in an unexpected state, and are advertized through svcs -x. (If it isn't supposed to be running, it should be disabled.) The framework can't sensibly distinguish between "I disabled a service, and it's OK that its enabled dependencies aren't running" and "I disabled a service, and it's not OK that its enabled dependencies aren't running". The framework assuming the former will lead to accidental misconfigurations not being diagnosed. Enabled services are expected to be running, so introducing models where that expectation is violated is inappropriate. If a service isn't expected to be running it should be disabled. Regardless of whether you believe there should be improvements in the future, this is the current model -- and polluting svcs -x output with more 'expected' failures leads to ongoing confusion. Every person who sees it gets to analyze whether this is an error they care about, which is antithetical to the goals of SMF and FMA. (I still need to read Alan's mail in detail... apologies to Alan for the lack of response to the underlying questions.) liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
