smf(5) 맨 페이지 - 윈디하나의 솔라나라




     smf - service management facility

     The Solaris service management facility defines  a  program-
     ming  model  for providing persistently running applications
     called services. The facility also provides the  infrastruc-
     ture  in  which  to  run services. A service can represent a
     running application, the software state of a  device,  or  a
     set  of  other  services.  Services  are  represented in the
     framework by service instance objects, which are children of
     service  objects.  Instance  objects can inherit or override
     the configuration of the parent service object, which allows
     multiple  service  instances to share configuration informa-
     tion. All service and instance objects are  contained  in  a
     scope that represents a collection of configuration informa-
     tion. The configuration of the  local  Solaris  instance  is
     called the "localhost" scope, and is the only currently sup-
     ported scope.

     Each service instance  is  named  with  a  fault  management
     resource  identifier  (FMRI) with the scheme svc:. For exam-
     ple, the syslogd(1M) daemon started at system startup is the
     default service instance named:


     Many commands also allow FMRI abbreviations. See the svcs(1)
     man page for one such example.

     In the above example, default is the name  of  the  instance
     and system/system-log is the service name. Service names can
     comprise multiple components separated by slashes  (/).  All
     components,  except  the  last,  compose the category of the
     service. Site-specific  services  should  be  named  with  a
     category beginning with site.

     A service instance is either enabled or disabled.  All  ser-
     vices  can  be  enabled or disabled with the svcadm(1M) com-

     The list of managed service instances on  a  system  can  be
     displayed with the svcs(1) command.

     When an administrator deletes an entity backed by a manifest
     or  profile  in  a standard location, that entity is masked,
     and is not seen by normal queries to SMF.  Masked entity can
     be  explored  using  svccfg  listcust, and removed using the
     delcust subcommand to svccfg.  See svccfg(1M) for details.

     Service instances can have dependencies on a set of entities
     which  can include services, instances, and files. Dependen-
     cies govern when the service is  started  and  automatically
     stopped. When the dependencies of an enabled service are not
     satisfied, the service is kept in the  offline  state.  When
     its  dependencies  are satisfied, the service is started. If
     the start is successful, the service is transitioned to  the
     online  state. Unlike services and instances, file dependen-
     cies are not evaluated dynamically as files are  created  or
     deleted. They are evaluated only one time.

     Whether a dependency  is  satisfied  is  determined  by  its

                     Satisfied when all cited services  are  run-
                     ning (online or degraded), or when all indi-
                     cated files are present.

                     Satisfied when one of the cited services  is
                     running  (online  or  degraded),  or when at
                     least one of the indicated files is present.

                     Satisfied if the cited services are  running
                     (online  or  degraded) or do not run without
                     administrative  action  (disabled,   mainte-
                     nance,  not  present, or offline waiting for
                     dependencies  which  do  not  start  without
                     administrative  action). Incomplete services
                     also satisfy optional dependencies.

                     Satisfied when all of the cited services are
                     disabled,  in the maintenance state, or when
                     cited services or files are not present.

     Once running (online or degraded), if a service cited  by  a
     require_all,  require_any,  or  optional_all  dependency  is
     stopped or refreshed, the SMF considers why the service  was
     stopped  and  the  restart_on attribute of the dependency to
     decide whether to stop the service.

                          |  restart_on value
       event              |  none  error restart refresh
       stop due to error  |  no    yes   yes     yes
       non-error stop     |  no    no    yes     yes
       refresh            |  no    no    no      yes

     A service is considered to have stopped due to an  error  if
     the  service  has encountered a hardware error or a software
     error such as a core dump. For exclude_all dependencies, the
     service  is  stopped if the cited service is started and the
     restart_on attribute is not none.

     The dependencies on a service can be listed with  svcs(1) or
     svccfg(1M), and modified with svccfg(1M).

     Each service is managed by a restarter. The  master  restar-
     ter,  svc.startd(1M)  manages  states  for the entire set of
     service instances and their dependencies. The master restar-
     ter  acts on behalf of its services and on delegated restar-
     ters that can provide specific  execution  environments  for
     certain  application  classes.  For instance, inetd(1M) is a
     delegated restarter that provides its service instances with
     an  initial  environment composed of a network connection as
     input and output file descriptors. Each  instance  delegated
     to  inetd(1M)  is in the online state. While the daemon of a
     particular instance might not be running,  the  instance  is
     available to run.

     As dependencies are satisfied when  instances  move  to  the
     online  state, svc.startd(1M) invokes start methods of other
     instances or directs the delegated restarter to do so. These
     operations might overlap.

     The current set of services and associated restarters can be
     examined  using  svcs(1). A description of the common confi-
     guration   used   by   all   restarters    is    given    in

     Each service or  service  instance  must  define  a  set  of
     methods  that start, stop, and, optionally, refresh the ser-
     vice. See smf_method(5) for a more complete  description  of
     the   method  conventions  for  svc.startd(1M)  and  similar
     fork(2)-exec(2) restarters.

     Administrative methods, such as for the  capture  of  legacy
     configuration information into the repository, are discussed
     on the svccfg(1M) manual page.

     The methods for a service can be listed and  modified  using
     the svccfg(1M) command.

     Each service instance is  always  in  a  well-defined  state
     based  on  its dependencies, the results of the execution of
     its methods, and its potential contracts events. The follow-
     ing states are defined:

                      This is the initial state for  all  service
                      instances.  Instances  are moved to mainte-
                      nance, offline, or a  disabled  state  upon
                      evaluation   by   svc.startd(1M)   or   the
                      appropriate restarter.

                      The instance is enabled, but not  yet  run-
                      ning or available to run. If restarter exe-
                      cution of the service start method  or  the
                      equivalent   method   is   successful,  the
                      instance  moves  to   the   online   state.
                      Failures   might  lead  to  a  degraded  or
                      maintenance  state.  Administrative  action
                      can lead to the uninitialized state.

                      The instance is enabled and running  or  is
                      available  to  run.  The specific nature of
                      the  online  state   is   application-model
                      specific  and  is  defined by the restarter
                      responsible  for  the   service   instance.
                      Online  is the expected operating state for
                      a  properly  configured  service  with  all
                      dependencies  satisfied.  Failures  of  the
                      instance can lead to a degraded or  mainte-
                      nance  state. Failures of services on which
                      the instance depends can lead to offline or
                      degraded states.

                      The instance  is  enabled  and  running  or
                      available to run. The instance, however, is
                      functioning at a limited capacity  in  com-
                      parison  to  normal  operation. Failures of
                      the instance can lead  to  the  maintenance
                      state.  Failures  of  services on which the
                      instance depends can  lead  to  offline  or
                      degraded  states.  Restoration  of capacity
                      should result in a transition to the online

                      The instance was not able to start, stop or
                      continue   running.  Administrative  action
                      (through  svcadm  clear,  after  corrective
                      steps  are  taken)  is required to move the
                      instance out of the maintenance  state.  If
                      the  instance  is disabled, the maintenance
                      state is temporary.  In  this  case,  if  a
                      svcadm  clear  is issued, the instance will
                      not re-execute the stop method that  caused
                      the   instance  to  enter  the  maintenance
                      state, but will simply revert to  the  dis-
                      abled state.

                      The instance is disabled. Enabling the ser-
                      vice results in a transition to the offline
                      state and eventually to  the  online  state
                      with all dependencies satisfied.

                      This state  represents  a  legacy  instance
                      that  is not managed by the service manage-
                      ment facility. Instances in this state have
                      been  started  at  some point, but might or
                      might not be running. Instances can only be
                      observed  using  the  facility  and are not
                      transferred into other states.

     States can also have transitions that result in a return  to
     the originating state.

  Events Notification
     SMF allows notification by using SNMP or SMTP of state tran-
     sitions.  It  publishes Information Events for state transi-
     tions which are consumed by notification daemons like  snmp-
     notify(1M)  and  smtp-notify(1M).  SMF  state transitions of
     disabled services do not generate notifications  unless  the
     final  state  for the transition is disabled and there exist
     notification parameters for that transition. Notification is
     not  be generated for transitions that have the same initial
     and final state.

  Notification Parameters
     Notification  parameters  for  FMA  Events  are  stored   in
     svc:/system/fm/notify-params:default  except for Information

     Events generated by SMF state transitions. Those are  stored
     in  the service or in the instance of the transitioning ser-
     vice. Notification parameters for SMF state transition  gen-
     erated    events    can    be    set    system    wide    in
     svc:/system/svc/global:default. The system wide notification
     parameters   are   used   when  a  composed  lookup,  as  in
     scf_instance_get_pg_composed(3SCF),  in  the   transitioning
     instance  cannot  be  found.  Notification parameters can be
     manipulated using svccfg(1M). Notification parameters can be
     configured  in  a  service  manifest  or  profile  using the
     notification_parameters element described  in  the  DTD.  An
     example is provided below:

            <event  value='from-online' />
            <type name='smtp' active="false">
               <parameter name='to'>
                   <value_node value='root@local' />
                   <value_node value='admin-alias@eng' />
            <type name='snmp' />

     events is a comma separated list  of  SMF  state  transition
     sets  or a comma separated list of FMA event classes. events
     cannot have a mix of SMF state transition sets and FMA event

     For       convenience,       the        tags        problem-
     {diagnosed,updated,repaired,resolved} describe the lifecycle
     of a problem diagnosed by the FMA subsystem -  from  initial
     diagnosis  to  interim  updates and finally problem closure.
     These tags are aliases for  underlying  FMA  protocol  event
     classes (all in the list.* hierarchy), but the latter should
     not be used in configuring notification preferences.

         A new problem has been diagnosed by the  FMA  subsystem.
         The  diagnosis  includes a list of one or more suspects,
         which (where appropriate) might have been  automatically
         isolated  to prevent further errors occurring. The prob-
         lem is identified by a UUID in the  event  payload,  and
         further  events  describing  the resolution lifecycle of
         this problem quote a matching UUID.

         One or more of the suspect resources in a problem  diag-
         nosis  has  been repaired, replaced or acquitted (or has
         been faulted again), but  there  remains  at  least  one
         faulted  resource  in  the  list.  A repair could be the
         result of an fmadm command line (fmadm  repaired,  fmadm
         acquit,  fmadm  replaced)  or  might  have been detected
         automatically such as through detection of a part serial
         number change.

         All of the suspect resources in a problem diagnosis have
         been repaired, resolved or acquitted. Some or all of the
         resources might still be isolated at this stage.

         All of the suspect resources in a problem diagnosis have
         been  repaired  resolved  or acquitted and are no longer
         isolated (for example, a cpu that was a suspect and off-
         lined  is  now back online again; this un-isolate action
         is usually automatic).

     State Transition Sets are defined as:

                     Set of all transitions that have <state>  as
                     the final state of the transition.

                     Set of all transitions that have <state>  as
                     the initial state of the transition.

                     Set of all transitions that have <state>  as
                     the initial state of the transition.

                     Set of all transitions.

     Valid values of state are  maintenance,  offline,  disabled,
     online and degraded. An example of a transitions set defini-
     tion: maintenance, from-online, to-degraded.

  Properties and Property Groups

     The dependencies, methods, delegated restarter, and instance
     state  mentioned above are represented as properties or pro-
     perty groups of the service or service instance.  A  service
     or  service  instance  has  an  arbitrary number of property
     groups in which to store application  data.  Using  property
     groups  in this way allows the configuration of the applica-
     tion to derive the attributes that the  repository  provides
     for  all  data in the facility. The application can also use
     the appropriate  subset  of  the  service_bundle(4)  DTD  to
     represent its configuration data within the framework.

     Property lookups are composed. If a property  group-property
     combination  is not found on the service instance, most com-
     mands and the high-level interfaces of  libscf(3LIB)  search
     for the same property group-property combination on the ser-
     vice that contains that instance. This allows common  confi-
     guration  among  service instances to be shared. Composition
     can be viewed as an  inheritance  relationship  between  the
     service instance and its parent service.

     Properties are protected from modification  by  unauthorized
     processes. See smf_security(5).

  General Property Group
     The general property group applies to all service instances.
     It includes the following properties:

     enabled (boolean)
                           Specifies  whether  the  instance   is
                           enabled.   If  this  property  is  not
                           present on an instance, SMF  does  not
                           tell  the  instance's  restarter about
                           the existence of the instance.

     restarter (fmri)
                           The restarter for  this  service.  See
                           the Restarters section for more infor-
                           mation. If this property is unset, the
                           default system restarter is used.

     complete (astring)
                           Whether this service is complete or is
                           a  partial  definition that should not
                           be started. This property is automati-
                           cally set on manifest import. Alterna-
                           tively, an instance without this  pro-
                           perty   that   successfully  validates
                           against the template definitions  (see
                           scf_tmpl_validate_fmri(3SCF))     will
                           have   this   property   created    by
                           svcadm(1M) on enable.

     The repository is assembled from a combination  of  adminis-
     trative  customization,  current  state,  and default values
     from files in standard locations. Services, instances,  pro-
     perty  groups,  and  properties defined by manifests in SMF-
     managed   filesystem   locations   are   always   accurately
     represented  in  the  repository. Customizations made during
     runtime by administrators or other programs are captured and
     stored in the repository.

     A property can have different values in the repository which
     reflect  different  settings  from  manifests, profiles, and
     administrative customizations. Which one is presented to the
     user and service by default is arbitrated by a simple prior-
     ity scheme called layers.

     Four layers are  tracked  by  SMF.  In  decreasing  priority
     order, they are:

                       Any change made by interactive use of  SMF
                       commands  or libraries. This layer has the
                       highest priority.

                       Any  values  from   the   files   in   the
                       /etc/svc/profile/site  directory,  or  the
                       legacy    /etc/svc/profile/site.xml    and
                       /var/svc/profile/site.xml files.

                       Any values from the system  profile  loca-
                       tions   /etc/svc/profile/generic.xml   and

                       Any values from the system manifest  loca-
                       tions         /lib/svc/manifest         or

     Property conflicts are not permitted within  any  individual
     layer.  A  conflicting  property  in  the admin layer simply
     overwrites the previous property. If the  same  property  is
     delivered  by  multiple files in any other layer, and is not
     set at a higher layer, the entire instance is tagged as  in-
     conflict,  and  are  not started by svc.startd(1M) until the
     conflicting definition is removed or the property is set  at
     a  higher  layer. Other libscf consumers requesting a single
     value, including svccfg and svcprop, see a  random  property
     setting  from  amongst  all  appropriate  values.  We do not
     guarantee which of the conflicting values are returned.

     Historical data about each instance  in  the  repository  is
     maintained  by the service management facility. This data is
     made available as  read-only  snapshots  for  administrative
     inspection and rollback. The following set of snapshot types
     might be available:

                 Initial configuration of the instance created by
                 the  administrator  or  produced  during package

                 Current configuration captured when an  adminis-
                 trative undo operation is performed.

                 The running configuration of the instance.

                 Configuration captured during a successful tran-
                 sition to the online state.

     The  svccfg(1M)  command  can  be  used  to  interact   with

  Special Property Groups
     Some property groups are  marked  as  non-persistent.  These
     groups  are  not backed up in snapshots and their content is
     cleared during system boot. Such groups  generally  hold  an
     active  program  state which does not need to survive system

  Configuration Repository
     The current state of each service instance, as well  as  the
     properties  associated  with services and service instances,
     is stored in a system repository managed by svc.configd(1M).

     The repository  for  service  management  facility  data  is
     managed by svc.configd(1M).

  Service Bundles, Manifests, and Profiles
     The  information  associated  with  a  service  or   service
     instance  that is stored in the configuration repository can
     be exported as XML-based files. Such  XML  files,  known  as
     service  bundles,  are portable and suitable for backup pur-
     poses.  Service  bundles  are  classified  as  one  of   the
     following types:

                  Files that contain the complete set of  proper-
                  ties associated with a specific set of services
                  or service instances.

                  Files that contain a set of  service  instances
                  and  values  for  the  enabled  property  (type
                  boolean in the general property group) on  each

                  Profiles can also contain configuration  values
                  for  properties in services and instances. Tem-
                  plate elements cannot be defined in a profile.

                  Profiles can use a relaxed set of elements from
                  the  DTD described in service_bundle(4). To use
                  these, the DOCTYPE entry should have  the  fol-
                  lowing definitions added:

                    <!ENTITY % profile "INCLUDE">
                    <!ENTITY % manifest "IGNORE">

     Service bundles can be imported or exported from  a  reposi-
     tory using the svccfg(1M) command. See service_bundle(4) for
     a description of the service bundle file format with  guide-
     lines for authoring service bundles.

     An smf milestone is a service  that  aggregates  a  multiple
     service dependencies. Usually, a milestone does nothing use-
     ful  itself,  but  declares  a  specific  state  of  system-
     readiness on which other services can depend. One example is
     the name-services milestone, which simply depends  upon  the
     currently enabled name services.

  Legacy Startup Scripts
     Startup programs in the /etc/rc?.d directories are  executed
     as part of the corresponding run-level milestone:




     Execution of each  program  is  represented  as  a  reduced-
     functionality  service instance named by the program's path.
     These instances are held in a special legacy-run state.

     These instances  do  not  have  an  enabled  property  (type
     boolean  in the general property group) and, generally, can-
     not be manipulated with the  svcadm(1M)  command.  No  error
     diagnosis or restart is done for these programs.

See Also
     svcs(1),   inetd(1M),   snmp-notify(1M),    smtp-notify(1M),
     svcadm(1M),   svccfg(1M),  svc.configd(1M),  svc.startd(1M),
     exec(2),               fork(2),                libscf(3LIB),
     scf_tmpl_validate_fmri(3SCF),   strftime(3C),   contract(4),
     service_bundle(4),     smf_bootstrap(5),      smf_method(5),
     smf_restarter(5), smf_security(5)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.