Smf:solaris System Service Management tool

SMF (the "predictable self-recovery technology" in Solaris 10, which includes both FMA and SMF) provides an infrastructure that expands on the basis of traditional UNIX startup scripts, init run levels, and configuration files.

I. The concept of SMF

To understand the SMF concept, you must first understand the following terms.

(1) SMF Services

The basic snap-in in the SMF framework is the service instance. It is possible for each SMF service to have multiple versions configured. Also, multiple instances of the same version can be run on a Solaris 10 system. An instance refers to 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 can have different configuration requirements. Services have system-wide configuration requirements, but each instance can override specific requirements as needed. Multiple instances of a single service can be managed as child objects of a service object. A service not only represents a standard system service (such as DHCPD or NFSD) that runs over a long period of time, it also represents various system entities that include ISV applications, such as Oracle software. In addition, the service may include less traditional entities, as shown below:

Physical network devices

Configured IP Address

Kernel configuration information

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

Typically, a service is an entity that provides a range of functionality to applications and other services (both local and remote). The service relies on an implicitly declared list of local services. Milestones are special types of services. The milestone service represents the advanced properties of the system. For example, services that make up run level S, 2, and 3 are represented by milestone services.

(2) Service identifier

Each service instance is named using the fault Management resource identifier (Fault Management Resource Identifier, FMRI). FMRI includes the service name and instance name. For example, the FMRI for the Rlogin service is Svc:/network/login:rlogin, where Network/login identifies the service, Rlogin identifies the service instance.

The equivalent format of the FMRI is as follows:

Svc://localhost/system/system-log:default

Svc:/system/system-log:default

System/system-log:default

In addition, some SMF commands can use this FMRI format: Svc:/system/system-log. Some commands infer which instance to use and when there is no ambiguity. For instructions on choosing the appropriate FMRI format, see the SMF Command man page.

A general functional category is typically included in the service name. These categories include:

Application

Device

Milestone

Network

Platform

Site

System

Traditional INIT.D scripts are also represented using an FMRI that starts with a LRC (instead of an SVC), for example: Lrc:/etc/rcs_d/s35cacheos_sh. You can use SMF to monitor legacy services.

(3) SMF compatibility

Although many standard Solaris services are now managed by SMF, scripts located in/ETC/RC*.D can continue to execute in run-level transformations. Most of the/ETC/RC*.D scripts included in previous Solaris releases have been removed as part of the SMF. The rest of the scripts can continue to run, adding third-party applications without having to convert the service to use SMF. In addition,/etc/inittab and/etc/inetd.conf must be available for packages that will be corrected using the installed script. These are called traditional running services. By running the Inetconv command, these traditional running services can be added to the service configuration repository. You can view the status of these services, but the SMF does not support other changes. Applications that use this feature will not benefit from the precise fault isolation provided by SMF. Applications that are converted to use SMF may no longer be able to modify/etc/inittab and/etc/inetd.conf files. The converted application will not use the/ETC/RC*.D script. Similarly, new versions of inetd do not find items in/etc/inetd.conf.