Manual Pages for UNIX Operating System command usage for man smf_bootstrap

Standards, Environments, and Macros              smf_bootstrap(5)



NAME
     smf_bootstrap - service management facility boot, packaging,
     and compatibility 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 pro-
     files.

  Manifest Loading at Boot
     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 mani-
     fest is imported, a hash of the file that includes its  con-
     tents   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 sup-
     ported    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 pro-
     cessing. This service  processes  only  manifests  from  the
     /lib/svc/manifest  directory tree before svc.startd(1M) ini-
     tializes 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)  com-
     mands  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



SunOS 5.11          Last change: 12 May 2010                    1






Standards, Environments, and Macros              smf_bootstrap(5)



       manifests  delivered  in  that directory tree prior to the
       introduction of system/early-manifest-import:default. Ser-
       vices   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.

  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  sub-
     system.  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 sys-
     tem is next rebooted with that alternate root path.

  Stability Declarations
     Each service group and each property group  delivered  in  a
     manifest  should  declare  a stability level based on attri-
     butes(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 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



SunOS 5.11          Last change: 12 May 2010                    2






Standards, Environments, and Macros              smf_bootstrap(5)



     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.

  Profile Application
     The first time the existence of each of  the  three  service
     profiles  listed below is detected, the profile is automati-
     cally 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 adminis-
     trative 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.

SEE ALSO
     svcs(1),  pkgadd(1M),  pkgrm(1M),  svcadm(1M),   svccfg(1M),
     svc.startd(1M),   libscf(3LIB),   service_bundle(4),  attri-
     butes(5), smf(5), smf_security(5)

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










SunOS 5.11          Last change: 12 May 2010                    3