| Skip Navigation Links | |
| Exit Print View | |
|
Managing Services and Faults in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Managing Services and Faults in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. Managing Services (Overview)
SMF Administrative and Programming Interfaces
SMF Command-Line Administrative Utilities
Service Management Configuration Library Interfaces
SMF Properties and Property Groups
Managing Information in the Service Configuration Repository
When to Use Run Levels or Milestones
Determining a System's Run Level
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 could be running multiple times on a system accounting for slightly different configurations. These different configurations are called service instances. Each instance is a specific configuration of a service. For example, 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. In addition, a service can represent less traditional entities such as the following:
A physical network device
A configured IP address
Kernel configuration information
Milestones that correspond to a 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 and explicitly declared list of local services.
A milestone is a special type of service. Milestone services represent a level of system readiness. For example, run levels are represented by milestones in SMF. Also, milestones can be used to indicate the readiness of a group of services, such as svc:/milestone/name-services:default for the name services or svc:/milestone/config:default for the sysconfig service.
Dependencies define the relationships between services. These relationships provide precise fault containment by restarting only those services that are directly affected by a fault, rather than restarting all of the services. Dependencies also provide a scalable and reproducible initialization process. Finally, the definition of precise dependencies allows system startup to take advantage of modern, highly parallel machines because all independent services can be started in parallel.
The restart behavior of a service is defined by the restart_on attribute for each dependency. A service can be configured to stop, if the service it is dependent on stops due to an error or for another reason, or is refreshed. After a service is stopped by this process, it will automatically be restarted as soon as the service it is dependent on starts. For example, the ssh service has a dependency on the network/ipfilter service. The restart_on attribute is set to error, which means that the ssh service will be stopped and automatically restarted if the network/ipfilter service stops due to an error. The ssh service will not be stopped if the other event types are encountered.
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, many SMF commands may use an abbreviated service or instance name, when there is no ambiguity. For example, system-log can be used directly rather than the longer formats. See the SMF command man pages, such as svcadm(1M) or svcs(1), for instructions on which FMRI formats are appropriate.
Service names include prefixes to help identify the purpose of each service. These prefixes include names such as application, device, milestone, network, or system. The site prefix is reserved for site-specific customizations, which means that a service named svc:/site/service-name will never conflict with the services delivered in an Oracle Solaris release.
Legacy init.d scripts are also represented with FMRIs that start with lrc instead of svc, for example, lrc:/etc/rc2_d/S47pppd. The legacy service's initial start times during system boot are displayed by using the svcs command. However, you cannot administer these services by using SMF.
During initial system deployment, 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 service 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. The inetconv command can be used to convert inetd.conf entries after initial system deployment.
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 asterisk “*” is appended to the state for instances in transition. A question mark “?” is displayed if the state is absent or unrecognized.
An SMF manifest is an XML file that describes a service and a set of instances. Manifests are imported to load the properties of that service and its instances into the service configuration repository. See the service_bundle(4) man page for a complete description of the contents of an SMF manifest. Also, see the svcbundle(1M) man page for a description of a tool which makes creating manifests easier.
The preferred location for manifests is /lib/svc/manifest. Manifests stored there will be imported and upgraded by the svc:/system/early-manifest-import:default service 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:/filesystem/minimal:default instance is online, which indicates that /var is mounted.
Do not make changes to manifests delivered by Oracle or third-party software vendors. Do not directly edit those manifests in /lib/svc/manifest and /var/svc/manifest, as any customizations will be lost upon upgrade. Instead, either create a site profile to customize the service, or use the svccfg or inetadm command to manipulate the properties directly. The /lib/svc/manifest/site and /var/svc/manifest/site directories are also reserved for site-specific use. The Oracle Solaris release will not deliver manifests into those directories.
In the Oracle Solaris 11 release, multiple manifests can be used to describe a single service. This can be useful, for example, to define a new instance of a service without modifying the service's existing manifest. If the same property in the same administrative layer for the same service or instance is defined by multiple manifests, SMF cannot determine which value to use. When this type of conflict is detected, the instance is placed in the maintenance state. See SMF Administrative Layers for a more information about layers.
An SMF profile is an XML file that allows customization of services and instances that are delivered by the system. Profiles are available for customization by using a file rather than a set of scripts, or to customize the configuration at deployment or installation time.
All configurations can be customized by using a profile.
Local customizations must be placed in files named with a .xml suffix in the /etc/svc/profile/site directory. All customizations in this directory are applied when the system is booted or when the svcadm restart manifest-import command is run.
As with manifests, any conflicting definitions between files in /etc/svc/profile/site are treated as conflicts, and the affected instances are placed in the maintenance state.
A system profile is also applied during installation. Changes to the system profile in /etc/svc/profile/generic.xml are rarely necessary. See the smf_bootstrap(5) man page for more information.
For more information about using profiles, see How to Apply an SMF Profile.
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. The service configuration repository can only be manipulated or queried by 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.
Properties in the repository can be defined on either the service or the instance. Properties that are set on the service are shared by all instances of that service. Properties that are set on the instance are used only by that instance and can override properties on the service.
The svccfg command offers a raw view of properties, and is precise about whether the properties are set on the service or the instance. If you view a service by using the svccfg command, you cannot see instance properties. If you view the instance instead, you cannot see service properties. The svcprop command offers a composed view of the instance, where both instance properties and service properties are combined into a single property namespace. When service instances are started, the composed view of their properties is used.
All SMF configuration changes can be logged by using the Oracle Solaris auditing framework. Refer to Configuring the Audit Service (Task Map) in Oracle Solaris 11.1 Administration: Security Services for more information.
In the Oracle Solaris 11 release, information that records the source of properties, property groups, instances, and services has been added to the service configuration repository. This information enables users to determine which data are administrative customizations and which data were delivered with the software.
To help identify the source of an entity, the following layers are defined:
The admin layer includes any changes that are made by using the SMF commands or by calling the libscf(3LIB) API.
The site-profile layer includes any values from the files in the /etc/svc/profile/site directory or the legacy /etc/svc/profile/site.xml and /var/svc/profile/site.xml profiles.
The system-profile layer includes any values from the system profile locations: /etc/svc/profile/generic.xml and /etc/svc/profile/platform.xml.
The manifest layer includes values from a system manifest directory: /lib/svc/manifest or /var/svc/manifest.
To maintain compatibility for existing clients who expect a single property per property name, as well as to create a policy for overrides, the layering has a simple override behavior. The admin layer takes precedence. If a property has a value in the admin layer, that is the value that is used by the service. If not, the site-profile layer is checked, followed by the system-profile layer, and finally the manifest layer. This behavior allows for local customizations to take precedence over the values that are provided when the system was installed.
These layers are managed automatically by the system. An administrator's direct changes to the repository appear only in the admin layer. Other layers are changed only by placing or removing files in standard locations. When a property is placed into the repository due to file contents, the information about that property includes the name of the file that the contents came from.
An administrator cannot modify the lower layers directly by using svccfg or libscf calls. When the svccfg delete, svccfg delpg, or svccfg delprop command is used, the entity will be masked instead of fully deleted. Normally, users cannot see the deleted entity, but masked entities can be explicitly explored by using the svccfg listcust command, and unmasked by using the svccfg delcust command, if desired. Exploring masked entities allows administrators to see what a configuration would look like after the mask is removed, and make changes if necessary without harming the running system.
The svccfg listprop command has options to enable the exploration of these layers. For example, svccfg listprop -l all prints all layers and the values in each layer. In addition, the svccfg listcust command can be used to list customizations only.
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 backups occur after svc:/system/early-manifest-import:default or svc:/system/manifest-import:default completes, if the service 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 – Taken when svcadm refresh is run
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 svccfg command is used to change current property values. Those values become visible to the service when the svcadm refresh command is run to integrate those values into the running snapshot. The svccfg command can also be used to view or revert to instance configurations in another snapshot.
Service-specific information, including errors the service or its methods emits, as well as information about enable actions, start times, and so on, are logged in individual files for each service instance in /var/svc/log. To determine the name of a service's log file, run the svcs -x service command.
By default, SMF writes log messages to the syslog program and the console only if administrative intervention is required, for example, if a service enters the maintenance state. Other options are available but rarely used. See the svc.startd(1M) man page for other potential configurations.
In addition, to error logging, the SMF service can be configured to notify you when an FMA event occurs or when services transition in to or out of a service state. These notifications can use the Simple Network Management Protocol (SNMP) or the Simple Mail Transfer Protocol (SMTP). See How to Set Up Notification of SMF Transition Events for information about setting up SMF notifications.
|