JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Managing Services and Faults in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


1.  Managing Services (Overview)

About SMF in this Release

Introduction to SMF

Advantages to Using SMF

SMF Concepts

SMF Service

SMF Dependencies

Service Identifiers

Service States

SMF Manifests

SMF Profiles

Service Configuration Repository

SMF Administrative Layers

SMF Repository Backups

SMF Snapshots

SMF Service Error Logging

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 Properties and Property Groups

Managing Information in the Service Configuration Repository

Viewing SMF Information

Modifying SMF Information

Deleting SMF Information

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

2.  Managing Services (Tasks)

3.  Using the Fault Manager


SMF Compatibility

Although many standard services are now managed by SMF, the scripts placed in /etc/rc*.d continue to be executed on run level transitions. Most of the /etc/rc*.d scripts that were included in previous releases have been removed as part of SMF. The ability to continue to run the remaining scripts allows for third-party applications to be added without having to convert the services to use SMF.

In addition, /etc/inittab entries also continue to be processed by the init command. Also, /etc/inetd.conf is available for packages to amend. During initial system deployment, services that are listed in /etc/inetd.conf are automatically converted into SMF services. Any later additions can be converted by using the inetconv command. The status of these services can be viewed, but no other changes are supported through SMF. Applications that use this conversion feature will not benefit from the precise fault containment provided by SMF. The latest version of inetd does not look for entries in /etc/inetd.conf to convert after the initial boot.

Applications that are converted to utilize SMF no longer need to make use of the mechanisms listed in this section.