illumos gate

http://openindiana.org/pipermail/openindiana-discuss/2013-February/011749.html

While setting up and maintaining systems there are occasions when an SMF service needs to be restarted - i.e. due to reconfiguration or its failure. An admin currently has to check the service's current state and depending on the results - pick the correct svcadm action. This part can/should be easily automated.

The RFE is to add some command (and pick what should it be called?) to try to "kick" a service into "online" state from whatever starting situation:

• for an already "online" service this would act as a "restart",
• for an "offline" service this would be an "enable",
• and a service in "maintenance" state this would "clear".

This should likely do nothing with services in transitional state (currently becoming online or offline, as marked with an asterisk - though maybe request restart of the latter), and of course the action may fail again (likely into maintenance) if the service is still misconfigured.

Also useful would be a number of enhancements for scripted and/or interactive modes:

• a "-s" option to not return until the service state-changes have all completed (like "svcadm disable/enable -s"); return a non-zero error-code if the service started into maintenance or remained disabled due to unfulfilled dependencies
• some option ("-v"?) to report service state after startup completes (like "svcs -p", and additionally "svcs -xv" if things are detected broken), so that systems maintenance does not require the admin to run sets of same commands over and over.

It is just annoying to have to verify the service's current state before "kicking" it, though I've spawned a simple admin-script on my systems to do this chore ;)

I think the solution should be a part of the common SMF structure in the svcadm binary.