Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

OpenSolaris 2009.06 - man page for smf_bootstrap (opensolaris section 5)

smf_bootstrap(5)	       Standards, Environments, and Macros		 smf_bootstrap(5)

       smf_bootstrap - 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.

   Manifest Loading at Boot
       The svc:/system/manifest-import:default service uses svccfg(1M) 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(1M) 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(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.

   Stability Declarations
       Each  service  group and each property group delivered in a manifest should declare a sta-
       bility 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.

   Property Overrides
       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  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  proper-
       ties.  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 manifest import tools to delete this property group from the  reposi-
       tory. 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(1M) automatically applies the profile.


       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(1M).

       pkgadd(1M),  pkgrm(1M), svcadm(1M), svccfg(1M), svc.startd(1M), libscf(3LIB), service_bun-
       dle(4), attributes(5), smf(5), smf_security(5)

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

SunOS 5.11				   25 Sep 2008				 smf_bootstrap(5)

All times are GMT -4. The time now is 07:04 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password