Tribblix: manual page: smf

SMF_BOOTSTRAP(7) Standards, Environments, and Macros SMF_BOOTSTRAP(7)

NAME

smf_bootstrap - service management facility boot, packaging, and
compatibility behavior

DESCRIPTION

The service management facility establishes conventions for
delivering service manifests, incorporating service manifest changes,
describing service configuration stability, using service
configuration overrides, and the use of service profiles.

Manifest Loading at Boot

The svc:/system/manifest-import:default service uses svccfg(8) to
import certain manifest files from the /var/svc/manifest directory
tree into the service configuration repository. The service imports
files that it has not imported previously and those files which have
changed since the last time they were imported by the service. When a
manifest is imported by the service, a hash of the file that includes
its contents is recorded in a property group of the svc:/smf/manifest
service. The manifest-import service uses the hash to determine
whether the file has changed. See svccfg(8) for information on the
svccfg import behavior for services that already exist in the
repository.

Manifest Handling During Packaging Operations

Service manifests within packages should be identified with the class
manifest. Class action scripts that install and remove service
manifests are included in the packaging subsystem. When pkgadd(8) is
invoked, the service manifest is imported.

When pkgrm(8) is invoked, instances in the manifest that are disabled
are deleted. Instances in the manifest that are online or degraded
are disabled first and then deleted. Any services in the manifest
with no remaining instances are also deleted.

If the -R option is supplied to pkgadd(8) or pkgrm(8), the actions
described in this section will be done when the system is next
rebooted with that alternate root path.

Stability Declarations

Each service group and each property group delivered in a manifest
should declare a stability level based on attributes(7) definitions.
With knowledge of the stability level, an application developer can
determine the likelihood that feature development based on the
existence or components of a service or object is likely to remain
functional across a release boundary.

In an smf(7) context, the stability value also identifies the
expected scope of the changes to properties within the property group
across a release boundary for the service, which can include patches
for that service. The following two sections discuss this in more
detail.

Property Overrides

The service_bundle(5) document type definition includes an override
attribute that is applicable to each property in a service manifest.
If set to true, the attribute instructs svccfg(8) and other manifest
import tools to replace the current value of a property in the
repository with the one from the manifest. If the override attribute
is absent or present but set to false, the current value in the
repository is preserved.

Property groups declared as Stable do not contain override attributes
on enclosed properties. Property groups declared as Evolving do so
only to correct an erroneous setting. Property groups declared as
Unstable can contain overrides on any property. The exception to this
behavior is for the stability property itself, which can be modified
to identify incipient change to the interface presented by the
service.

Property Group Deletion

The service_bundle(5) document type definition includes a delete
attribute, applicable to each property group in a service manifest.
If set to true, the delete attribute instructs svccfg(8) and other
manifest import tools to delete this property group from the
repository. If the delete attribute is absent or present but set to
false, the property group in the repository is preserved.

Property groups declared as Stable or Evolving are not deleted.
Property groups declared as Unstable can be deleted across any
release boundary.

Profile Application

The first time the existence of each of the three service profiles
listed below is detected, svc.startd(8) automatically applies the
profile.

/var/svc/profile/generic.xml
/var/svc/profile/platform.xml
/var/svc/profile/site.xml

The svc:/smf/manifest service is used in a similar fashion.

Additional service profiles that characterize the activation of
various groups of service instances might be present in
/var/svc/profile. None of the /var/svc/profile profiles are
automatically applied to the repository. A profile can be manually
applied or re-applied using svccfg(8).

NOTES

The present version of smf(7) does not support multiple repositories.

September 25, 2008 SMF_BOOTSTRAP(7)