| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 5: Standards, Environments, and Macros Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 5: Standards, Environments, and Macros Oracle Solaris 11.1 Information Library |
- service management facility boot, packaging, and compatibility behavior
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.
Manifests from the standard directory trees /lib/svc/manifest and /var/svc/manifest are processed during system boot and anytime an administrator 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 determine 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 upgraded 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 service, is responsible for the first manifest processing. This service processes only manifests from the /lib/svc/manifest directory tree before svc.startd(1M) initializes any services thus enabling services delivered in /lib/svc/manifest to always start with their most updated definition. Since this is a pseudo service, svcadm(1M) commands are ignored though svcs(1) can be used to observe status and get log file information.
The svc:/system/manifest-import:default service handles the second manifest 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 system/early-manifest-import:default. Services delivered in /var/svc/manifest can run into upgrade-related issues where a service might be started with an old repository configuration because its updated manifest 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 encouraged to move a manifest to /lib/svc/manifest to avoid these issues.
Only *.xml files are considered for the operations described in this section.
Profiles are also applied by the early-manifest-import and manifest-import services.
The system-delivered profiles in /etc/svc/profile/generic.xml and /etc/svc/profile/platform.xml are imported into the system-profile layer.
Site-specific profiles in the /etc/svc/profile/site directory and legacy site files /etc/svc/profile/site.xml and /var/svc/profile/site.xml are imported into the site-profile layer.
Administrators can request that these profiles are reapplied by running:
$ 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.
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 pkg install is invoked, the service manifest is imported.
When pkg uninstall 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.
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 existence or components of a service or object is likely to remain functional 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 a delete attribute, applicable to each property group in a service manifest. If set to true, the delete attribute instructs svccfg(1M) 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.
svcs(1), svcadm(1M), svccfg(1M), svc.startd(1M), libscf(3LIB), service_bundle(4), attributes(5), smf(5), smf_security(5)
The present version of smf(5) does not support multiple repositories.
|