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.
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 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.
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:
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
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:
In addition, the syntax for a converted service that uses the RPC
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.
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.
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.
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 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.
/var/svc/profile/platform_*.xml – These profiles enable services associated with particular hardware platforms.
During the first boot after a new installation or an upgrade to
the Solaris 10 release or any of the subsequent Solaris Express releases, 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
For more information about using profiles, see How to Apply an SMF Profile.
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.
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 svcadm refresh command, sometimes followed by the svcadm restart 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.