svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
smf_bootstrap(7)
sm...p(7)Standards, Environments, Macros, Character Sets, and miscellansym...p(7)
NAME
smf_bootstrap - service management facility boot, packaging, and com‐
patibility 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
Manifests from the standard directory trees /lib/svc/manifest and
/var/svc/manifest are processed during system boot and anytime an ad‐
ministrator or program runs:
$ svcadm restart manifest-import
Manifests that have not been imported previously or have changed since
the last time they were imported are processed. A hash is used to de‐
termine whether a manifest has changed.
When a manifest in a standard location is imported for the first time,
its properties, instances, and services are added to the repository as
part of the manifest layer.
Manifests in standard locations are automatically imported when they
are updated. New services and instances are added, properties are up‐
graded if they are changed, and services, instances, and properties are
deleted if they are removed.
Manifests are processed in two different phases during boot.
The service svc:/system/early-manifest-import:default, a pseudo ser‐
vice, is responsible for the first manifest processing. This service
processes only manifests from the /lib/svc/manifest directory tree be‐
fore svc.startd(8) initializes any services thus enabling services de‐
livered in /lib/svc/manifest to always start with their most updated
definition. Since this is a pseudo service, svcadm(8) commands are ig‐
nored though svcs(1) can be used to observe status and get log file in‐
formation.
The svc:/system/manifest-import:default service handles the second man‐
ifest processing and imports manifest files from both /lib/svc/manifest
and /var/svc/manifest directory trees, in that respective order.
Support for /var/svc/manifest is compatibility support for manifests
delivered in that directory tree prior to the introduction of sys‐
tem/early-manifest-import:default. Services delivered in /var/svc/mani‐
fest can run into upgrade-related issues where a service might be
started with an old repository configuration because its updated mani‐
fest is not yet imported. Similarly, a newly added service might not be
available or a deleted service is still started during boot because its
manifest file has not been processed. Developers are strongly encour‐
aged to move a manifest to /lib/svc/manifest to avoid these issues.
Only *.xml files are considered for the operations described in this
section.
Profile Application
Profiles are also applied by the early-manifest-import and manifest-im‐
port services.
The system-delivered profile in the file /etc/svc/profile/generic.xml
and the directory /etc/svc/profile/system are imported into the system-
profile layer.
Customer-specific profiles in the /etc/svc/profile/enterprise,
/etc/svc/profile/site, /etc/svc/profile/node, and /etc/svc/pro‐
file/sysconfig directories are imported into the enterprise-profile,
site-profile, node-profile and sysconfig-profile layers. The legacy
site file /etc/svc/profile/site.xml is imported into the node-profile
layer.
Administrators can request that these profiles are reapplied by run‐
ning:
$ svcadm restart manifest-import
The behavior of properties, instances, and services defined by profiles
is identical to those defined by manifests.
Only *.xml files are considered for the operations described in this
section.
Manifest Handling During Packaging Operations
Service manifests within packages should be identified with the class
manifest. Class action scripts that install and remove service mani‐
fests are included in the packaging subsystem. When pkg install is in‐
voked, the service manifest is imported.
When pkg uninstall is invoked, instances in the manifest that are dis‐
abled are deleted. Instances in the manifest that are online or de‐
graded are disabled first and then deleted. Any services in the mani‐
fest with no remaining instances are also deleted.
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 de‐
termine 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 Group Deletion
The service_bundle(5) document type definition includes a delete at‐
tribute, applicable to each property group in a service manifest. If
set to true, the delete attribute instructs svccfg(8) 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
boundary.
SEE ALSO
svcs(1), libscf(3LIB), service_bundle(5), attributes(7), smf(7),
smf_security(7), svc.startd(8), svcadm(8), svccfg(8)
NOTES
The present version of smf(7) does not support multiple repositories.
Oracle Solaris 11.4 19 Sept 2016 sm...p(7)