JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Basic Administration     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information


1.  Managing User Accounts and Groups (Overview)

2.  Managing User Accounts and Groups (Tasks)

3.  Introduction to Shutting Down and Booting a System

4.  Shutting Down and Booting a System (Overview)

5.  Shutting Down a System (Tasks)

6.  Modifying Oracle Solaris Boot Behavior (Tasks)

7.  Booting an Oracle Solaris System (Tasks)

8.  Troubleshooting Booting an Oracle Solaris System (Tasks)

9.  Managing the Oracle Solaris Boot Archives (Tasks)

10.  x86: GRUB Based Booting (Reference)

11.  Managing Services (Overview)

Introduction to SMF

Changes in Behavior When Using SMF

SMF Concepts

SMF Service

Service Identifiers

Service States

SMF Manifests

SMF Profiles

Service Configuration Repository

SMF Repository Backups

SMF Snapshots

SMF Administrative and Programming Interfaces

SMF Command-Line Administrative Utilities

Service Management Configuration Library Interfaces

SMF Components

SMF Master Restarter Daemon

SMF Delegated Restarters

SMF and Booting

SMF Compatibility

Run Levels

When to Use Run Levels or Milestones

Determining a System's Run Level

/etc/inittab File

What Happens When the System Is Brought to Run Level 3

12.  Managing Services (Tasks)


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 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:

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:

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:

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 protocol is:


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:

SMF Manifests

An SMF manifest is an XML file that that describes a service and a set of instances. Manifests are imported to load the properties of that service and its instances into the repository.

The preferred location for manifests is /lib/svc/manifest. Manifests stored there will be imported and upgraded during the boot process before any services start. Running the import process early ensures that the repository will contain information from the latest manifests before the services are started. At other times you can import information from these manifests by running this command: svcadm restart manifest-import. /var/svc/manifest remains available for compatibility purposes, but manifests located there will not be imported or upgraded until the svc:/system/manifest-import:default service runs, which is significantly later in the boot process.

The site subdirectory of /lib/svc/manifest and /var/svc/manifest is reserved for site-specific use. Manifests in the site directory may be modified directly. Other manifests included in the software release should not be modified since those modifications will be lost during software upgrades. If changes need to be made to the set of properties included in the generic manifests, either create a profile or use the svccfg command.

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 release include:

During the first boot after a new installation or an upgrade, some profiles are automatically applied. To be specific, the /etc/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 /etc/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.

Like manifests, profiles in /etc/svc/profile will be applied during the early manifest import. Profiles in /var/svc/profile will be applied during the later manifest import.

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 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:

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:

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, incorporates current property values into the running snapshot. 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.