smf_bootstrap(5) Standards, Environments, and Macros smf_bootstrap(5)
smf_bootstrap - service management facility boot, packaging, and com-
The service management facility defines a series of conventions for
importing the configuration contained within a service manifest or pro-
file into a repository.
Manifest loading at boot
At system start, svc.startd(1M) run in default mode begins processing
the manifests located in /var/svc/manifest and importing new or changed
manifests into the repositorty.
The decision to import a service manifest is based on the existence of
a property group in the svc:/smf/manifest service with the following
o The name of the property group is the name of the imported mani-
fest with non-alphanumeric characters replaced by underscore (_)
o The properties of the property group are set based on the manifest
The manifest is not reimported in the event that configuration changes
are made to the repository by an administrator. Such configuration
changes might include the deletion of one or more services or service
instances contained within the manifest. The /var/svc/manifest/site
directory is provided for site-specific customizations.
The deletion of a property group by means of svccfg(1M) or libscf(3LIB)
interfaces allows the manifest to be reimported on a subsequent system
Manifest handling during packaging operations
Service manifests within packages are identified with the class mani-
fest. Class action scripts that install and remove service manifests
are included in the packaging subsystem. When pkgadd(1M) is invoked,
the service manifest is imported.
When pkgrm(1M) is invoked, instances in the manifest that are disabled
are deleted. Any services in the manifest with no remaining instances
are also deleted.
Each service group and each property group delivered in a manifest
should declare a stability level based on attributes(5) definitions.
With knowledge of the stability level, an application developer can
determine the likelihood that feature development based on the exis-
tence or components of a service or object is likely to remain func-
tional across a release boundary.
In an smf(5) 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.
The service_bundle(4) 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(1M) and other manifest
import tools to replace the current value of a property in the reposi-
tory with the one from the manifest. If the override attribute is
absent or present but set to false, the current value in the repository
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(4) 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(1M) and other mani-
fest import tools to delete this property group from the repository. If
the delete attribute is absent or present but set to false, the prop-
erty group in the repository is preserved.
Property groups declared as Stable or Evolving are not deleted. Prop-
erty groups declared as Unstable can be deleted across any release
The first time the existence of each of the three service profiles
listed below is detected, svc.startd(1M) automatically applies the pro-
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
pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), svc.startd(1M), lib-
scf(3LIB), service_bundle(4), attributes(5), smf(5), smf_security(5)
The present version of smf(5) does not support multiple repositories.
SunOS 5.10 27 Aug 2004 smf_bootstrap(5)