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


맨 페이지 이름


Standards, Environments, and Macros                                     smf(5)

       smf - service management facility

       The Solaris service management facility defines a programming model for
       providing persistently running applications called services. The facil‐
       ity  also  provides the infrastructure in which to run services. A ser‐
       vice 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  information. All service and instance objects are
       contained in a scope that  represents  a  collection  of  configuration
       information.  The configuration of the local Solaris instance is called
       the "localhost" scope, and is the only currently supported scope.

       Each service instance is named with a fault management resource identi‐
       fier  (FMRI)  with the scheme svc:. For example, 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 sys‐
       tem/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 services can be
       enabled or disabled with the svcadm(1M) command.

       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  nor‐
       mal  queries  to SMF.  Masked entity can be explored using svccfg list‐
       cust, and removed using the delcust subcommand  to  svccfg.   See  svc‐
       cfg(1M) for details.

       Service  instances can have dependencies on a set of entities which can
       include services, instances, and files. Dependencies  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  off‐
       line  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 dependencies are not
       evaluated dynamically as files are created or deleted. They are  evalu‐
       ated only one time.

       Whether a dependency is satisfied is determined by its grouping:

       require_all     Satisfied  when  all cited services are running (online
                       or degraded), or when all indicated files are present.

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

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

       exclude_all     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   restarter,
       svc.startd(1M)  manages  states for the entire set of service instances
       and their dependencies. The master restarter acts on behalf of its ser‐
       vices  and  on delegated restarters 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  out‐
       put  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 configuration  used  by  all
       restarters is given in smf_restarter(5).

       Each  service  or  service  instance  must define a set of methods that
       start, stop, and, optionally, refresh the  service.  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

       The methods for a service can be listed and  modified  using  the  svc‐
       cfg(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 following states are defined:

       UNINITIALIZED    This  is  the initial state for all service instances.
                        Instances are moved to maintenance, offline, or a dis‐
                        abled  state  upon evaluation by svc.startd(1M) or the
                        appropriate restarter.

       OFFLINE          The instance is enabled, but not yet running or avail‐
                        able  to  run.  If  restarter execution 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.  Administra‐
                        tive action can lead to the uninitialized state.

       ONLINE           The instance is enabled and running or is available to
                        run. The specific nature of the online state is appli‐
                        cation-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 maintenance
                        state. Failures of  services  on  which  the  instance
                        depends can lead to offline or degraded states.

       DEGRADED         The  instance  is  enabled and running or available to
                        run. The instance, however, is functioning at  a  lim‐
                        ited capacity in comparison to normal operation. Fail‐
                        ures 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 state.

       MAINTENANCE      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  tempo‐
                        rary.  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 disabled state.

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

       LEGACY-RUN       This state represents a legacy instance  that  is  not
                        managed  by the service management 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 origi‐
       nating state.

   Events Notification
       SMF allows notification by using SNMP or SMTP of state transitions.  It
       publishes  Information  Events for state transitions 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:/sys‐
       tem/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 service. Notification parameters for SMF
       state transition generated events can be set system wide  in  svc:/sys‐
       tem/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 notifica‐
       tion_parameters element described in the DTD. An  example  is  provided

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

       For       convenience,       the       tags       problem-       {diag‐
       nosed,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  under‐
       lying 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  diagno‐
           sis includes a list of one or more suspects, which (where appropri‐
           ate) might have been  automatically  isolated  to  prevent  further
           errors  occurring. The problem 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 diagnosis 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


           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 offlined is now back online
           again; this un-isolate action is usually automatic).

       State Transition Sets are defined as:

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

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

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

       all             Set of all transitions.

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

   Properties and Property Groups
       The dependencies, methods, delegated restarter, and instance state men‐
       tioned above are represented as properties or property  groups  of  the
       service or service instance. A service or service instance has an arbi‐
       trary number of property groups in which  to  store  application  data.
       Using  property  groups  in  this  way  allows the configuration of the
       application 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 commands and the  high-level
       interfaces  of libscf(3LIB) search for the same property group-property
       combination on the service that contains  that  instance.  This  allows
       common  configuration 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 information. 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 prop‐
                             erty  is  automatically  set  on manifest import.
                             Alternatively, an instance without this  property
                             that  successfully validates against the template
                             definitions  (see   scf_tmpl_validate_fmri(3SCF))
                             will  have this property created by svcadm(1M) on

       The repository is assembled from a combination of  administrative  cus‐
       tomization,  current  state,  and default values from files in standard
       locations. Services, instances, property 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 reposi‐

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

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

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

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

       system-profile    Any  values  from  the   system   profile   locations
                         /etc/svc/profile/generic.xml     and    /etc/svc/pro‐

       manifest          Any  values  from  the  system   manifest   locations
                         /lib/svc/manifest or /var/svc/manifest.

       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 svc‐
       cfg and svcprop, see a random property setting from amongst all  appro‐
       priate  values. We do not guarantee which of the conflicting values are

       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  follow‐
       ing set of snapshot types might be available:

       initial     Initial configuration of the instance created by the admin‐
                   istrator or produced during package installation.

       previous    Current configuration captured when an administrative  undo
                   operation is performed.

       running     The running configuration of the instance.

       start       Configuration  captured  during  a successful transition to
                   the online state.

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

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

   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

   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 suit‐
       able  for backup purposes. Service bundles are classified as one of the
       following types:

       manifests    Files that contain the complete set of properties  associ‐
                    ated with a specific set of services or service instances.

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

                    Profiles can also contain configuration values for proper‐
                    ties in services and instances. Template  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 following definitions added:

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

       Service bundles can be imported or exported from a repository using the
       svccfg(1M) command. See service_bundle(4) for a description of the ser‐
       vice bundle file format with guidelines for authoring service bundles.

       An smf milestone is a service that aggregates a multiple service depen‐
       dencies. Usually, a milestone does nothing useful 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:

       /etc/rcS.d    milestone/single-user:default

       /etc/rc2.d    milestone/multi-user:default

       /etc/rc3.d    milestone/multi-user-server:default

       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, cannot be manipulated with the
       svcadm(1M) command. No error diagnosis or restart  is  done  for  these

       svcs(1),  inetd(1M), snmp-notify(1M), smtp-notify(1M), svcadm(1M), svc‐
       cfg(1M),  svc.configd(1M),  svc.startd(1M),  exec(2),   fork(2),   lib‐
       scf(3LIB),   scf_tmpl_validate_fmri(3SCF),  strftime(3C),  contract(4),
       service_bundle(4), smf_bootstrap(5),  smf_method(5),  smf_restarter(5),

SunOS 5.11                        13 Feb 2014                           smf(5)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.