SMF Concepts

This section presents terms and their definitions within the SMF framework.
These terms are used throughout the documentation. To grasp SMF concepts,
an understanding of these terms is essential.

SMF Service

The fundamental unit of administration in the SMF framework is
the service instance. Each SMF service has the potential
to have multiple versions of it configured. As well, multiple instances of
the same version can run on a single Oracle Solaris system. An instance is a specific configuration of a service. A web server is a service.
A specific web server daemon that is configured to listen on port 80 is an
instance. Each instance of the web server service could have different configuration
requirements. The service has system-wide configuration requirements, but
each instance can override specific requirements, as needed. Multiple instances
of a single service are managed as child objects of the service object.

Services are not just the representation for standard long-running system
services such as in.dhcpd or nfsd. Services
also represent varied system entities that include ISV applications such as
Oracle software. In addition, a service can include less traditional entities
such as the following:

A physical network device

A configured IP address

Kernel configuration information

Milestones that correspond to system init state, such as the
multiuser run level

Generically, a service is an entity that provides a list of capabilities
to applications and other services, local and remote. A service is dependent
on an implicitly declared list of local services.

A milestone is a special type of service. Milestone
services represent high-level attributes of the system. For example, the services
which constitute run levels S, 2, and 3 are each represented by milestone
services.

Service Identifiers

Each service instance is named with a Fault Management Resource Identifier
or FMRI. The FMRI includes the service name and the instance name. For example,
the FMRI for the rlogin service is svc:/network/login:rlogin, where network/login identifies the service
and rlogin identifies the service instance.

Equivalent formats for an FMRI are as follows:

svc://localhost/system/system-log:default

svc:/system/system-log:default

system/system-log:default

In addition, some SMF commands can use the following FMRI format: svc:/system/system-log. Some commands infer what instance to use,
when there is no ambiguity. See the SMF command man pages, such as svcadm(1M) or svcs(1), for instructions about which FMRI formats are appropriate.

The service names usually include a general functional category. The
categories include the following:

application

device

milestone

network

platform

site

system

Legacy init.d scripts are also represented with
FMRIs that start with lrc instead of svc,
for example: lrc:/etc/rcS_d/S35cacheos_sh. The legacy services
can be monitored using SMF. However, you cannot administer these services.

When booting a system for the first time with SMF, services listed in /etc/inetd.conf are automatically converted into SMF services.
The FMRIs for these services are slightly different. The syntax for a converted inetd services is:

network/<service-name>/<protocol>

In addition, the syntax for a converted service that uses the RPC protocol
is:

network/rpc-<service-name>/rpc_<protocol>

Where <service-name> is the name defined
in /etc/inetd.conf and <protocol> is
the protocol for the service. For instance, the FMRI for the rpc.cmsd service
is network/rpc-100068_2-5/rpc_udp.

Service States

The svcs command displays the state, start time,
and FMRI of service instances. The state of each service is one of the following:

degraded – The service instance is
enabled, but is running at a limited capacity.

disabled – The service instance is
not enabled and is not running.

legacy_run – The legacy service is
not managed by SMF, but the service can be observed. This state is only used
by legacy services.

maintenance – The service instance
has encountered an error that must be resolved by the administrator.

offline – The service instance is
enabled, but the service is not yet running or available to run.

online – The service instance is
enabled and has successfully started.

uninitialized – This state is the
initial state for all services before their configuration has been read.

SMF Manifests

An SMF manifest is an XML file that
contains a complete set of properties that are associated with a service or
a service instance. The files are stored in /var/svc/manifest.
Manifests should not be used to modify the properties of a service. The service
configuration repository is the authoritative source of configuration information.
To incorporate information from the manifest into the repository, you must
either run svccfg import or allow the service to import
the information during a system boot.

See the service_bundle(4) man page for a complete description of the contents
of the SMF manifests. If you need to change the properties of a service, see
the svccfg(1M) or inetadm(1M) man pages.

SMF Profiles

An
SMF profile is an XML file that lists a set of service
instances and whether each should be enabled or disabled. Some profiles which
are delivered with the Oracle Solaris release include:

/var/svc/profile/generic_open.xml –
This profile enables the standard services that have been started by default
in earlier Solaris releases.

/var/svc/profile/generic_limited_net.xml –
This profile disables many of the internet services that have be started by
default in earlier Solaris releases. The network/ssh service
is enabled to provide network connectivity.

/var/svc/profile/ns_*.xml – These
profiles enable services associated with the name service that is configured
to run on the system.

During the first boot after a new installation or an upgrade to the
Oracle Solaris OS,
some Solaris profiles are automatically applied. To be specific, the /var/svc/profile/generic.xml profile is applied. This file is usually symbolically linked to generic_open.xml or generic_limited_net.xml.
Also, if a profile called site.xml is in /var/svc/profile during the first boot or is added between boots, the contents of
this profile are applied. By using the site.xml profile,
the initial set of enabled services may be customized by the administrator.

Service Configuration Repository

The service configuration repository stores
persistent configuration information as well as SMF runtime data for services.
The repository is distributed among local memory and local files. SMF is designed
so that eventually, service data can be represented in the network directory
service. The network directory service is not yet available. The data in the
service configuration repository allows for the sharing of configuration information
and administrative simplicity across many Solaris instances. The service configuration
repository can only be manipulated or queried using SMF interfaces. For more
information about manipulating and accessing the repository, see the svccfg(1M) and svcprop(1) man pages. The service configuration
repository daemon is covered in the svc.configd(1M) man page. The service configuration
library is documented in the libscf(3LIB) man
page.

SMF Repository Backups

SMF automatically takes the following backups of the repository:

The boot backup is taken immediately before the first change
to the repository is made during each system startup.

The manifest_import backup occurs after svc:/system/manifest-import:default completes, if it imported any
new manifests or ran any upgrade scripts.

Four
backups of each type are maintained by the system. The system deletes the
oldest backup, when necessary. The backups are stored as /etc/svc/repository-type-YYYYMMDD_HHMMSWS,
where YYYYMMDD (year, month, day) and HHMMSS (hour, minute, second), are the date and time when the backup
was taken. Note that the hour format is based on a 24–hour clock.

You can restore the repository from these backups, if an error occurs.
To do so, use the /lib/svc/bin/restore_repository command.
For more information, see How to Repair a Corrupt Repository.

SMF Snapshots

The data in the service configuration
repository includes snapshots, as well as a configuration
that can be edited. Data about each service instance is stored in the snapshots.
The standard snapshots are as follows:

initial – Taken on the first import
of the manifest

running – Used when the service methods
are executed

start – Taken at the last successful
start

The SMF service always executes with the running snapshot.
This snapshot is automatically created if it does not exist.

The svcadmrefresh command,
sometimes followed by the svcadmrestart command, makes a snapshot active. The svccfg command
is used to view or revert to instance configurations in a previous snapshot.
See How to Revert to Another SMF Snapshot for
more information.