svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
smf(7)
Standards, Environments, Macros, Character Sets, and miscellany
smf(7)
NAME
smf - service management facility
DESCRIPTION
The Oracle Solaris service management facility defines a programming
model for providing persistently running applications called services.
The facility also provides the infrastructure 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 information. All service and instance objects are
contained in a scope that represents a collection of configuration
information. The configuration of the local Oracle 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(8) daemon
started at system startup is the default service instance named:
svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default
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(8) 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. For more
information, see the svccfg(8) man page.
Service and Instance Namespace
An instance name must begin with an alphanumeric character and can con‐
tain alphanumeric characters, underscore (_), hyphen (-), and dot (.).
One comma (,) is allowed between the first and last character for
names. For example:
ORCL, rcapd
com.oracle, rcapd
Service names allow multiple level of identifiers, each under the same
restrictions as instance names, to be delimited by slash (/). For exam‐
ple, system/svc/restarter.
Only ASCII characters are allowed.
Dependencies
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
dependencies.
Defines a startup order if the cited services are
present. Generally, it is unsatisfied if the cited ser‐
vices are present, enabled, and not yet running. It is
satisfied if the cited services are in online,
degraded, disabled, maintenance, or are absent or
incomplete state. It is also satisfied if the cited
services are offline due to an absent dependency or an
unsatisfied dependency that is in the disabled or main‐
tenance state. This dependency type is not recommended
for file dependencies, but if used it will behave as a
require_all dependency.
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(8),
and modified with svccfg(8).
Restarters
Each service is managed by a restarter. The master restarter,
svc.startd(8) 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(8) is
a delegated restarter that provides its service instances with an ini‐
tial environment composed of a network connection as input and output
file descriptors. Each instance delegated to inetd(8) 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(8) 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(7).
Methods
Each service or service instance must define a set of methods that
start, stop, and, optionally, refresh the service. See smf_method(7)
for a more complete description of the method conventions for
svc.startd(8) 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(8) manual
page.
The methods for a service can be listed and modified using the svc‐
cfg(8) command.
States
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 state is the initial state for all service
instances, including newly created instances (through
executing svccfg add, importing a manifest, or apply‐
ing a profile). When an instance is cleared from the
maintenance state (svcadm clear), it is placed in the
uninitialized state so that its restarter can re-eval‐
uate its configuration. Instances are moved to mainte‐
nance, offline, or disabled state after evaluation by
the appropriate restarter. Note that evaluation of an
instance can only occur if its restarter service is
online.
INCOMPLETE The instance is not completely installed on the system
and has not been evaluated by its restarter. The
instance is mentioned solely in a profile (and not
explicitly marked complete in the profile), or is men‐
tioned only as a dependent of another service.
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 functioning at a limited capacity in
comparison 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. Failure of instance meth‐
ods, can also lead to the degraded state. 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. When an
instance is cleared, SMF will transition the instance
to its configured state. If the instance is disabled,
SMF will move it to the disabled state. If the
instance is enabled, SMF will attempt to bring the
instance online.
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(8) and smtp-notify(8). 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(8). Notification parameters can be con‐
figured in a service manifest or profile using the notification_parame‐
ters element described in the DTD. An example is provided below:
<notification_parameters>
<event value='from-online' />
<type name='smtp' active="false">
<parameter name='to'>
<value_node value='root@local' />
<value_node value='admin-alias@eng' />
</parameter>
</type>
<type name='snmp' />
</notification_parameters>
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 life cycle 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.
problem-diagnosed
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 life cycle of
this problem quote a matching UUID.
problem-updated
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
change.
problem-repaired
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.
problem-resolved
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 in an offline state, 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, and
those property groups may be nested within other property group ele‐
ments allowing for the representation of complex hierarchical applica‐
tion configuration 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(5) DTD to repre‐
sent 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(7).
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 par‐
tial definition that should not be started.
This property is automatically set on mani‐
fest import. Alternatively, an instance with‐
out this property that successfully validates
against the template definitions (see
scf_tmpl_validate_fmri(3SCF)) will have this
property created by svcadm(8) on enable.
goal-service (boolean) When set to true, activates the behavior of
goal services. For more information, see the
Goal Services section for details.
Layers
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‐
tory.
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.
Seven layers are tracked by SMF. In decreasing priority order, they
are:
admin Any change made by interactive use of SMF com‐
mands or libraries. This layer has the highest
priority.
sysconfig-profile Any values from the files in the /etc/svc/pro‐
file/sysconfig directory. This directory is
exclusively used by the Oracle Solaris installer
and sysconfig. Certain sysconfig(8) operations
may remove all profiles from this directory.
node-profile Any values from the files in the /etc/svc/pro‐
file/node directory or the legacy /etc/svc/pro‐
file/site.xml file. These files are intended to
represent configuration that is unique to a par‐
ticular instance of Oracle Solaris.
site-profile Any values from the files in the /etc/svc/pro‐
file/site directory. These files are intended to
represent configuration that is common to many
systems located in a common location.
enterprise-profile Any values from the files in the /etc/svc/pro‐
file/enterprise directory. These files are
intended to represent configuration that is com‐
mon to most systems in a distributed population
of the Oracle Solaris instances.
system-profile Any values from the /etc/svc/profile/system
directory and the files /etc/svc/pro‐
file/generic.xml and /etc/svc/profile/plat‐
form.xml
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(8) 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 is
returned.
The enterprise-profile, site-profile, and node-profile layers are
intended to allow generally useful settings to be applied across a
large number of systems, while allowing easy overrides for groups of
systems and individual systems. For example, a company might have a set
of DNS services that is typically used by all servers, but require spe‐
cialized settings for certain sites or individual machines. Profiles
can be selectively delivered into the various layers using the
zoneadm(8) install. For more information, see the solaris(7) and the
solaris-kz(7) man pages.
Snapshots
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(8) 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(8).
The repository for service management facility data is managed by
svc.configd(8).
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(5). 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(8) command. See service_bundle(5) for a description of the ser‐
vice bundle file format with guidelines for authoring service bundles.
Milestones
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.
Existing milestones on Oracle Solaris include: none, config, devices,
unconfig, network, single-user, name-services, self-assembly-complete,
multi-user, and multi-user-server.
Goal Services
System administrators may use goal services to define the expected set
of services that should be running when a system is up and functioning
for its intended purpose.
Goal services are expected to have all their dependencies satisfiable.
If administrative intervention is required to have a dependency satis‐
fied, the goal service is placed in the maintenance state. Goal ser‐
vices that are in the maintenance state will automatically leave that
state once their dependencies are satisfiable.
In general, the goal service setting should not be used for services
that perform actual work.
It is not recommended to have goal services depending on dynamically
enabled services. Dynamically enabled services will lead a goal service
into the maintenance state until they are enabled by another service.
The admin can use svcadm(8) subcommand goals to set the dependencies of
goal services.
milestone/goals
The milestone/goals is a goal service with the purpose of providing a
clear, unambiguous, and well-defined point where a system can be con‐
sidered up and running. The dependencies of milestone/goals must be
configured to represent the mission critical services for the system.
The default dependency of milestone/goals is:
svc:/milestone/multi-user-server:default
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(8) command. No error diagnosis or restart is done for these pro‐
grams.
SEE ALSO
svcs(1), exec(2), fork(2), strftime(3C), libscf(3LIB), scf_tmpl_vali‐
date_fmri(3SCF), contract(5), service_bundle(5), smf_bootstrap(7),
smf_method(7), smf_restarter(7), smf_security(7), inetd(8), smtp-
notify(8), snmp-notify(8), svc.configd(8), svc.startd(8), svcadm(8),
svccfg(8), solaris(7), solaris-kz(7), zoneadm(8)
Oracle Solaris 11.4 9 May 2018 smf(7)