Something that perhaps I didn't focus on enough is that the interface provided through svcadm (and its behaviour) isn't at all intuitive to anyone who has used any of the other service startup mechanisms elsewhere.
That doing "disable" for a "Started service" that is "offline" is some how required or correct just doesn't gel, not to mention that "disable" is the required verb for stopping a service. The following are all quite seperate actions used when administering services: - disabling them - enabling them - starting them - stopping them I disable a service that I don't want to start up at the next boot. I enable a service that I want to start next boot. I stop something I don't want to run now. I start something that I want to run now. Started/stopped/enabled/disabled. Nothing there about "temporary" enable/disable - that is not the right paradigm for this kind of interface. Given that we have svc.startd and it has knowledge about what commands have been issued and what state a service is in, there needs to be better reflection of this in output from svcs. We have online/offline/disabled. Two extras that seem no brainers would be "starting" and "stopping". Possibly also "start failed" and "stop failed", rather than relying on the magic '*' to convey meaning. The lines "State:" and "Reason" in 'svcs -x' output should make sense when viewed together. It would also be nice if svcs could somehow display a graph f the services expected state migration as a result of commands that it has received from an administrator. With svcadm returning _no_ feedback (either positive or negative) there is no "comfort factor" in knowing that what you've just done with it on the command line worked vs was ignored or didn't work. For example, if 'svcs -x' had been able to tell me: "Starting -> Running -> Stopping -> Disabled" after I had done "svcadm disable", then at least I know it has heard me and I can concentrate on thinking about what is stopping it from entering "Running" rather than "did it ignore me?". For better or worse, I'm always suspicious of commands that always return 0 and try to convey a sense of "everything is how you want it." Disabling should not and does not need to imply anything to do with changing the current running state. The same goes for enabling. Microsoft understands this, the SVR4 rc implementation makes this possible, BSD rc-ng does, as to do the various Linux rc implementations. I believe that SMF needs to be much more intuitive in this area, especially for those that use it in a heterogenous environment. I know this might sound strange, but I quite like the design of SMF, it's just that when something goes wrong (DHCP server is dead at bootup) it is not a whole lot of fun to work with, to the point of it being quite frustrating when various commands don't quite work as expected. Darren
