The service management facility provides means for computer administrators to observe and control software services. Each service is modeled as an instance of an SMF service, which allows for a single service implementation to be executed multiple times simultaneously, as many are capable of doing.
Services and service instances are named by character strings. For example, the service implemented by
cron is named
system/cron, and Solaris includes an instance of it named
default. Tools usually refer to service instances with fault management resource identifiers, or FMRIs, which combine the service name and the instance name. The FMRI of the default instance of
svc:/system/cron:default. The service instances known to SMF can be listed with the
svcs -acommand. For convenience, most SMF tools accept abbreviations for service FMRIs.
Service implementations are controlled by the SMF service manager,
svc.startd. The current status and other information for service instances are printed by the
svcs command. The
-l option produces long output, like the following:
unixadmin.net# svcs -l cron fmri svc:/system/cron/:default name clock daemon (cron) enabled true state online next_state none state_time Thu Mar 16 18:25:50 2017 logfile /var/svc/log/system=cron:default.log/system restarter svc:/system/svc/restarter:default contract_id 66 dependency require_all/none svc:/system/filesystem/local (online) dependency require_all/none svc:/milestone/name-services (online)
The first line, labeled
fmri, contains the full FMRI of the service instance. The
name line provides a short description. The remaining output is explained later.
The service manager considers each service instance to be enabled or disabled. When enabled, the service manager will attempt to start a service instance’s implementation and restart it as necessary; when disabled, the facility will try to stop the implementation if it has been started. Whether a service is enabled can be changed with
state, next_state, and
To decide whether a service implementation should be started, the service manager always considers each service instance to be in one of six states.
|disabled||The service implementation has not been started, or has been stopped.|
|offline||The service is not running, but will be started when its dependencies are met.|
|online||The service has started successfully.|
|degraded||The service is running, but at reduced functionality or performance.|
|maintenace||An operation failed and administrative intervention is required.|
|uninitialized||The service’s restarter has not taken control of the service.|
While a service is in a stable state, the
next_state field is
none. While an operation to change the state of a service is incomplete,
next_state will contain the target state. For example, before a service implementation is started the service manager sets the
online, and if the operation succeeds, the service manager changes
state_time line lists the time the
next_state fields were updated. This time is not necessarily the last time the service instance changed states since SMF allows transitions to the same state.
The service manager logs some information about service events to a separate file for each service instance. This field gives the name of that file.
The service’s restarter interacts with the service’s implementation, and the contract ID identifies the processes that implement the service.
These lines list the dependencies of the service instance. SMF dependencies represent dependencies of the service implementation on other services. The service manager uses dependencies to determine when to start, and sometimes when to stop, service instances.
Each dependency has a grouping and a set of FMRIs. The grouping dictates when a dependency should be considered satisfied. SMF recognizes four dependency groupings.
|require_all||All services indicated by the FMRIs must be in the online or degraded states to satisfy the dependency.|
|require_any||At least one cited service must be online or degraded to satisfy the dependency.|
|optional_all||The dependency is considered satisfied when all cited services are online, degraded, disabled, in the maintenance state, or are offline and will eventually come online without administrative intervention. Services that don’t exist are ignored.|
|exclude_all||All cited services must be disabled or in the maintenance state to satisfy the dependency.|
When a service is enabled, the service manager will not start it until all of its dependencies are satisfied. Until then, the service will remain in the
The service manager can also stop services according to dependencies. This behavior is governed by the
restart_on value of the dependency, which may take one of four values.
|none||Do not stop the service if the dependency service is stopped.|
|error||Stop the service if the dependency is stopped due to a software or hardware error.|
|restart||Stop the service if the dependency if the dependency is stopped for any reason.|
|refresh||Stop the service if the dependency is stopped or its configuration is changed(refreshed).|