Jordan Brown writes: > Renaud Manus wrote: > > The current behavior when we disable an instance is to stop the instance > > first then notify the dependents (that have restart_on set to restart or > > refresh) so they can be stopped and transition to the 'offline' state. > > This is the correct behavior with respect to the specs of SMF states > > graph. > > I'm quite surprised at this behavior; it seems completely wrong. > Services should never be running when the services that they depend on > are not running. > > (I suppose that that rule must be violated when a service dies, when you > have no choice but to shut down dependents after the dependency, but I > would say that it should never be violated in non-failure cases.) > > Please, make the change. If you really must retain the current wrong > behavior, make *it* the option.
Another possible way to maintain consistency would be to make a bare "svcadm disable ..." on a service with active dependents fail, and require either "-f" (force == pretend as though a failure occurred, and do the same as today) or "-r" (recursive == administratively disable dependents in reverse order first, and then shut down this service) to handle this case. I'm no fan of the "must dial 1 first" school of interface design, but I'm not sure that having failure into offline mode occur in two different orders (reverse order if done by administrative action, forward order if done by actual service failure) is a good thing. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
