Dependency order. Services sometimes depend on one another for proper operation, and a robust system should know each service's dependencies. If an underlying service fails, it needs to be corrected before other services that depend upon it are affected.
Configurable boot verbosity
Delegation of tasks to non-root users. A service can be configured to run within a limited set of privileges, rather than as the all-powerful root user. If a service has been compromised, the amount of damage that can be inflicted by the intruder will be minimized if the service's power is constrained to that of a more limited user.
Parallel starting of services. This speeds up the boot process by starting multiple services simultaneously, allowing idle CPU time resulting from a service that is temporarily blocked to be relinquished for use by other services that can start independently of the blocked service.
Automatic service restart after failure. Works in conjunction with the Solaris Fault Manager, allowing software recovery in the event of hardware faults (CPU, memory), admin error such as accidental kills, and software core dumps.
All these capabilities are made possible by treating Services as "first class objects". That is, they are more than just user-executed software to the OS. They can be defined to have special states that allow finer control and permit monitoring and probing for diagnosing software failures, rather than having the administrator or dedicated "restarter" modules kill and restart the service as before.[2]
What are services?
Services are software objects that provide a set of capabilities to other software.[3] For example, a webserver provides HTTP service to web browsers. Other services include NFS for sharing files on a network, DHCP for dynamic IP address assignment, and Secure Shell for remote logins. Even higher level functions can be services, such as specific databases for e-commerce, finance, manufacturing control, etc. Typically, services are automatically started at boot up, long-lived, have common states (e.g. running, not running), relationship & dependencies (Sendmail service depends on Naming service, which depends on Networking services), and are critical to the dedicated function of the server.
What it replaces
In versions of Solaris prior to Solaris 10, and in UNIX in general, services are configured in text files, with startup files in the /etc/rc.d/ directory trees, and configuration data in files such as /etc/inittab and /etc/inetd.conf. A typical system could have dozens of configuration files, and configuration could involve various methods, including editing shell scripts. With SMF, there is one consistent interface to ease administration.
There has been no traditional definition or constraint of what a service is, making administration difficult. With SMF, each service can have a set of defined states, allowing admins to control services in a consistent way based on their state.
SMF concepts
Instances: a service is a collection of configurations. An instance is a running execution of a defined service executable. One can have many instances of a defined service, such as multiple webservers listening on different ports referencing different WWW root directories.
^Nicholas A. Solter, Jerry Jelinek, David Miner - 2011 OpenSolaris Bible p 490 1118080319 "A restarter is a process or, more properly, a service, that is responsible for monitoring and restarting other services. UNIX has actually had a form of a restarter since the very beginning, and it exists on all versions of UNIX-derived systems:"