| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 5: Standards, Environments, and Macros Oracle Solaris 11 Express 11/10 |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 5: Standards, Environments, and Macros Oracle Solaris 11 Express 11/10 |
- 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 are processed in two different phases during boot. In each phase, manifests are processed using svccfg(1M) to import manifest files from well-known locations into the service configuration repository. Imported manifest files are those that have not been imported previously or have changed since the last time they were imported. When a manifest is imported, a hash of the file that includes its contents is recorded in a property group of the svc:/smf/manifest service. The hash is used to determine whether the file has changed. See svccfg(1M) for information on the svccfg import behavior for services that already exist in the repository. For manifests installed under supported directory trees, /lib/svc/manifest and /var/svc/manifest, the manifest-import process will remove services and instances from the repository if manifest(s) delivering those services were deleted form the system. Instances will be removed from the repository if support for those instances are removed from the supporting manifest files.
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.
Note - 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.
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(1M) is invoked, the service manifest is imported.
When pkgrm(1M) 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(1M) or pkgrm(1M), the actions described in this section will be done when the system is next rebooted with that alternate root path.
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.
The first time the existence of each of the three service profiles listed below is detected, the profile is automatically applied.
/etc/svc/profile/generic.xml /etc/svc/profile/platform.xml /etc/svc/profile/site.xml /var/svc/profile/site.xml
Except for the three mentioned profiles, none of the /etc/svc/profile profiles are automatically applied to the repository. A profile can be manually applied or re-applied using svccfg(1M).
The /etc/svc/profile/site directory is delivered to contain additional site-specific profiles that also get applied by system manifest import services. Administrators and administrative tools can place new profiles into this directory and restart system/manifest-import or reboot the system to apply the new profiles.
The svc:/smf/manifest service is used in a similar fashion.
svcs(1), pkgadd(1M), pkgrm(1M), 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.
|