This chapter provides an overview of the Service Management Facility (SMF). In addition, information that is related to run levels is provided.SMFoverviewservice management facilitySMFnew featuresSMFservice management facilitySMFThis is a list of the overview information in this chapter.Introduction to SMF SMF Concepts SMF Administrative and Programming Interfaces SMF Components SMF Compatibility Run Levels /etc/inittab File For information on the procedures associated with SMF, see Managing Services (Task Map). For information on the procedures associated with run levels, see Using Run Control Scripts (Task Map). SMF provides an infrastructure that augments the traditional UNIX start-up scripts, init run levels, and configuration files. SMF provides the following functions:Automatically restarts failed services in dependency order, whether they failed as the result of administrator error, software bug, or were affected by an uncorrectable hardware error. The dependency order is defined by dependency statements. Makes services objects that can be viewed, with the new svcs command, and managed, with svcadm and svccfg commands. You can also view the relationships between services and processes using svcs p, for both SMF services and legacy init.d scripts. Makes it easy to backup, restore, and undo changes to services by taking automatic snapshots of service configurations. Makes it easy to debug and ask questions about services by providing an explanation of why a service isn't running by using svcs x. Also, this process is eased by individual and persistent log files for each service. Allows for services to be enabled and disabled using svcadm. These changes can persist through upgrades and reboots. If the t option is used, the changes are temporary. Enhances the ability of administrators to securely delegate tasks to non-root users, including the ability to modify properties and enable, disable, or restart services on the system. Boots faster on large systems by starting services in parallel according to the dependencies of the services. The opposite process occurs during shutdown. Allows you to customize the boot console output to either be as quiet as possible, which is the default, or to be verbose by using boot m verbose. Preserves compatibility with existing administrative practices wherever possible. For example, most customer and ISV-supplied rc scripts still work as usual. dependency statements (SMF)descriptionDependency statements define the relationships between services. These relationships can be used to provide precise fault containment by restarting only those services that are directly affected by a fault, rather than restarting all of the services. Another advantage of dependency statements is that the statements allow for scalable and reproducible initialization processes. In addition, by defining all of the dependencies, you can take advantage of modern, highly parallel machines, because all independent services can be started in parallel.restarters (SMF)descriptionSMF defines a set of actions that can be invoked on a service by an administrator. These actions include enable, disable, refresh, restart, and maintain. Each service is managed by a service restarter which carries out the administrative actions. In general, the restarters carry out actions by executing methods for a service. Methods for each service are defined in the service configuration repository. These methods allow the restarter to move the service from one state to another state.repository (SMF)descriptionThe service configuration repository provides a per-service snapshot at the time that each service is successfully started so that fallback is possible. In addition, the repository provides a consistent and persistent way to enable or disable a service, as well as a consistent view of service state. This capability helps you debug service configuration problems. Most of the features that are provided by SMF happen behind the scenes, so users are not aware of them. Other features are accessed by new commands. Here is a list of the behavior changes that are most visible.The boot process creates many fewer messages now. Services do not display a message by default when they are started. All of the information that was provided by the boot messages can now be found in a log file for each service that is in /var/svc/log. You can use the svcs command to help diagnose boot problems. In addition, you can use the v option to the boot command, which generates a message when each service is started during the boot process. Since services are automatically restarted if possible, it may seem that a process refuses to die. If the service is defective, the service will be placed in maintenance mode, but normally a service is restarted if the process for the service is killed. The svcadm command should be used to stop the processes of any SMF service that should not be running. Many of the scripts in /etc/init.d and /etc/rc*.d have been removed. The scripts are no longer needed to enable or disable a service. Entries from /etc/inittab have also been removed, so that the services can be administered using SMF. Scripts and inittab entries that are provided by an ISV or are locally developed will continue to run. The services may not start at exactly the same point in the boot process, but they are not started before the SMF services, so that any service dependencies should be OK. This section presents terms and their definitions within the SMF framework. These terms are used throughout the documentation. To grasp SMF concepts, an understanding of these terms is essential.service (SMF)descriptionThe fundamental unit of administration in the SMF framework is the service instance. Each SMF service has the potential to have multiple versions of it configured. As well, multiple instances of the same version can run on a single Solaris system. An instance is a specific configuration of a service. A web server is a service. A specific web server daemon that is configured to listen on port 80 is an instance. Each instance of the web server service could have different configuration requirements. The service has system-wide configuration requirements, but each instance can override specific requirements, as needed. Multiple instances of a single service are managed as child objects of the service object.Services are not just the representation for standard long-running system services such as in.dhcpd or nfsd. Services also represent varied system entities that include ISV applications such as Oracle software. In addition, a service can include less traditional entities such as the following:A physical network device A configured IP address Kernel configuration information Milestones that correspond to system init state, such as the multiuser run level Generically, a service is an entity that provides a list of capabilities to applications and other services, local and remote. A service is dependent on an implicitly declared list of local services.A milestone is a special type of service. Milestone services represent high-level attributes of the system. For example, the services which constitute run levels S, 2, and 3 are each represented by milestone services. FMRIdescription fault management resource identifierFMRI Each service instance is named with a Fault Management Resource Identifier or FMRI. The FMRI includes the service name and the instance name. For example, the FMRI for the rlogin service is svc:/network/login:rlogin, where network/login identifies the service and rlogin identifies the service instance.Equivalent formats for an FMRI are as follows:svc://localhost/system/system-log:default svc:/system/system-log:default system/system-log:default In addition, some SMF commands can use the following FMRI format: svc:/system/system-log. Some commands infer what instance to use, when there is no ambiguity. See the SMF command man pages, such as svcadm1M or svcs1, for instructions about which FMRI formats are appropriate.The service names usually include a general functional category. The categories include the following:application device milestone network platform site system Legacy init.d scripts are also represented with FMRIs that start with lrc instead of svc, for example: lrc:/etc/rcS_d/S35cacheos_sh. The legacy services can be monitored using SMF. However, you cannot administer these services.When booting a system for the first time with SMF, services listed in /etc/inetd.conf are automatically converted into SMF services. The FMRIs for these services are slightly different. The syntax for a converted inetd services is:network/<service-name>/<protocol>In addition, the syntax for a converted service that uses the RPC protocol is:network/rpc-<service-name>/rpc_<protocol>Where <service-name> is the name defined in /etc/inetd.conf and <protocol> is the protocol for the service. For instance, the FMRI for the rpc.cmsd service is network/rpc-100068_2-5/rpc_udp. service statesdescription The svcs command displays the state, start time, and FMRI of service instances. The state of each service is one of the following:degraded – The service instance is enabled, but is running at a limited capacity. disabled – The service instance is not enabled and is not running. legacy_run – The legacy service is not managed by SMF, but the service can be observed. This state is only used by legacy services. maintenance – The service instance has encountered an error that must be resolved by the administrator. offline – The service instance is enabled, but the service is not yet running or available to run. online – The service instance is enabled and has successfully started. uninitialized – This state is the initial state for all services before their configuration has been read. manifests (SMF)description An SMF manifest is an XML file that contains a complete set of properties that are associated with a service or a service instance. The files are stored in /var/svc/manifest. Manifests should not be used to modify the properties of a service. The service configuration repository is the authoritative source of configuration information. To incorporate information from the manifest into the repository, you must either run svccfg import or allow the service to import the information during a system boot.See the service_bundle4 man page for a complete description of the contents of the SMF manifests. If you need to change the properties of a service, see the svccfg1M or inetadm1M man pages. profiles (SMF)description An SMF profile is an XML file that lists a set of service instances and whether each should be enabled or disabled. Some profiles which are delivered with the Solaris release include:/var/svc/profile/generic_open.xml – This profile enables the standard services that have been started by default in earlier Solaris releases. /var/svc/profile/generic_limited_net.xml – This profile disables many of the internet services that have be started by default in earlier Solaris releases. The network/ssh service is enabled to provide network connectivity. /var/svc/profile/ns_*.xml – These profiles enable services associated with the name service that is configured to run on the system. /var/svc/profile/platform_*.xml – These profiles enable services associated with particular hardware platforms. During the first boot after a new installation or an upgrade to the Solaris 10 release or any of the subsequent Solaris Express releases, some Solaris profiles are automatically applied. To be specific, the /var/svc/profile/generic.xml profile is applied. This file is usually symbolically linked to generic_open.xml or generic_limited_net.xml. Also, if a profile called site.xml is in /var/svc/profile during the first boot or is added between boots, the contents of this profile are applied. By using the site.xml profile, the initial set of enabled services may be customized by the administrator.For more information about using profiles, see How to Apply an SMF Profile. repository (SMF)descriptionservice configuration repositoryrepositoryconfiguration repository (SMF)repositoryThe service configuration repository stores persistent configuration information as well as SMF runtime data for services. The repository is distributed among local memory and local files. SMF is designed so that eventually, service data can be represented in the network directory service. The network directory service is not yet available. The data in the service configuration repository allows for the sharing of configuration information and administrative simplicity across many Solaris instances. The service configuration repository can only be manipulated or queried using SMF interfaces. For more information about manipulating and accessing the repository, see the svccfg1M and svcprop1 man pages. The service configuration repository daemon is covered in the svc.configd1M man page. The service configuration library is documented in the libscf3LIB man page. SMF automatically takes the following backups of the repository:The boot backup is taken immediately before the first change to the repository is made during each system startup. The manifest_import backup occurs after svc:/system/manifest-import:default completes, if it imported any new manifests or ran any upgrade scripts. Four backups of each type are maintained by the system. The system deletes the oldest backup, when necessary. The backups are stored as /etc/svc/repository-type-YYYYMMDD_HHMMSWS, where YYYYMMDD (year, month, day) and HHMMSS (hour, minute, second), are the date and time when the backup was taken. Note that the hour format is based on a 24–hour clock.You can restore the repository from these backups, if an error occurs. To do so, use the /lib/svc/bin/restore_repository command. For more information, see How to Repair a Corrupt Repository. snapshots (SMF)description The data in the service configuration repository includes snapshots, as well as a configuration that can be edited. Data about each service instance is stored in the snapshots. The standard snapshots are as follows:initial – Taken on the first import of the manifest running – Used when the service methods are executed start – Taken at the last successful start The SMF service always executes with the running snapshot. This snapshot is automatically created if it does not exist.The svcadm refresh command, sometimes followed by the svcadm restart command, makes a snapshot active. The svccfg command is used to view or revert to instance configurations in a previous snapshot. See How to Revert to Another SMF Snapshot for more information. This section introduces the interfaces that are available when you use SMF.commands (SMF)list of SMFcommands SMF provides a set of command-line utilities that interact with SMF and accomplish standard administrative tasks. The following utilities can be used to administer SMF.Command Name Function inetadm Provides the ability to observe or configure services controlled by inetdinetadm commanddescription svcadm Provides the ability to perform common service management tasks, such as enabling, disabling, or restarting service instancessvcadm commanddescription svccfg Provides the ability to display and manipulate the contents of the service configuration repositorysvccfg commanddescription svcprop Retrieves property values from the service configuration repository with a output format appropriate for use in shell scriptssvcprop commanddescription svcs Gives detailed views of the service state of all service instances in the service configuration repositorysvcs commanddescription SMFlibrary interfaces library interfacesSMF SMF provides a set of programming interfaces that are used to interact with the service configuration repository through the svc.configd daemon. This daemon is the arbiter of all requests to the local repository datastores. A set of fundamental interfaces is defined as the lowest level of interaction possible with services in the service configuration repository. The interfaces provide access to all service configuration repository features such as transactions and snapshots.Many developers only need a set of common tasks to interact with SMF. These tasks are implemented as convenience functions on top of the fundamental services to ease the implementation burden. SMF includes a master restarter daemon and delegated restarters.svc.startddaemondescription The svc.startd daemon is the master process starter and restarter for the Solaris OS. The daemon is responsible for managing service dependencies for the entire system. The daemon takes on the previous responsibility that init held of starting the appropriate /etc/rc*.d scripts at the appropriate run levels. First, svc.startd retrieves the information in the service configuration repository. Next, the daemon starts services when their dependencies are met. The daemon is also responsible for restarting services that have failed and for shutting down services whose dependencies are no longer satisfied. The daemon keeps track of service state through an operating system view of availability through events such as process death. SMFdelegated restarters delegated restarters (SMF) restarters (SMF) Some services have a set of common behaviors on startup. To provide commonality among these services, a delegated restarter might take responsibility for these services. In addition, a delegated restarter can be used to provide more complex or application-specific restarting behavior. The delegated restarter can support a different set of methods, but exports the same service states as the master restarter. The restarter's name is stored with the service. A current example of a delegated restarter is inetd, which can start Internet services on demand, rather than having the services always running. SMF provides new methods for booting a system. For instance:There is a additional system state which is associated with the all milestone. With the all milestone, all of the services with a defined dependency on the multi-user-server milestone are started, as well as any services that do not have a defined dependency. If you have added services, such as third party products, they may not be started automatically unless you use the following command:ok boot -m milestone=all When booting a system, you can choose to use the verbose option to see more messages. By default, the system will not display these messages. To boot in the verbose mode, use the following command:ok boot -mverbose There is a new system state which is associated with the none milestone. Only init, svc.startd and svc.configd are started if you boot a system using this milestone. This state can be very useful for debugging booting problems. In particular, debugging any problems with the configuration of SMF services is made simpler, because none of the services are started. See How to Boot Without Starting Any Services for instructions on how to use the none milestone. While many standard Solaris services are now managed by SMF, the scripts placed in /etc/rc*.d continue to be executed on run-level transitions. Most of the /etc/rc*.d scripts that were included in previous Solaris releases have been removed as part of SMF. The ability to continue to run the remaining scripts allows for third-party applications to be added without having to convert the services to use SMF.In addition, /etc/inittab and /etc/inetd.conf must be available for packages to amend with postinstall scripts. These are called legacy-run services. The inetconv command is run to add these legacy-run services to the service configuration repository. The status of these services can be viewed, but no other changes are supported through SMF. Applications that use this feature will not benefit from the precise fault containment provided by SMF.Applications converted to utilize SMF should no longer make modifications to the /etc/inittab and /etc/inetd.conf files. The converted applications will not use the /etc/rc*.d scripts. Also, the new version of inetd does not look for entries in /etc/inetd.conf. run leveldefinitionrun leveldefault run levelinit statesrun levelsA system's run level (also known as an init state) defines what services and resources are available to users. A system can be in only one run level at a time. The Solaris OS has eight run levels, which are described in the following table. The default run level is specified in the /etc/inittab file as run level 3.Run Level Init State Type Purpose 0 Power-down state Power-down run level0 (power-down level)To shut down the operating system so that it is safe to turn off power to the system. run levels or S (single-user level)s or S single-user levelrun level s or SSingle-user state Single-user To run as a single user with some file systems mounted and accessible. 1 Administrative state Single-user run level1 (single-user level)To access all available file systems. User logins are disabled. 2 Multiuser state Multiuser run level2 (multiuser level)For normal operations. Multiple users can access the system and all file system. All daemons are running except for the NFS server daemons. 3 multiuser levelrun level 3Multiuser level with NFS resources shared Multiuser run level3 (multiuser with NFS)For normal operations with NFS resources shared. This is the default run level for the Solaris OS. 4 Alternative multiuser state Not configured by default, but available for customer use. 5 Power-down state Power-down To shut down the operating system so that it is safe to turn off power to the system. If possible, automatically turns off power on systems that support this feature. 6 Reboot state Reboot run level6 (reboot level)To shut down the system to run level 0, and then reboot to multiuser level with NFS resources shared (or whatever level is the default in the inittab file). In addition, the svcadm command can be used to change the run level of a system, by selecting a milestone at which to run. The following table shows which run level corresponds to each milestone.Run Level SMF Milestone FMRI S milestone/single-user:default 2 milestone/multi-user:default 3 milestone/multi-user-server:default Under most circumstances, using the init command with a run level to change the system state is sufficient. Using milestones to change system state can be confusing and can lead to unexpected behavior. In addition, the init command allows for the system to be shutdown, so init is the best command for changing system state.However, booting a system using the none milestone, can be very useful when debugging startup problems. There is no equivalent run level to the none milestone. See How to Boot Without Starting Any Services for specific instructions. Display run level information by using the who -r command.$ who -rrun leveldetermining (how to)who commanddeterminingsystem's run level (how to)Use the who -r command to determine a system's current run level for any level. This example displays information about a system's current run level and previous run levels.$ who -r . run-level 3 Dec 13 10:10 3 0 S $Output of who r command Description run-level 3 Identifies the current run level Dec 13 10:10 Identifies the date of last run level change 3 Also identifies the current run level 0 Identifies the number of times the system has been at this run level since the last reboot S Identifies the previous run level /etc/inittab fileWhen you boot the system or change run levels with the init or shutdown command, the init daemon starts processes by reading information from the /etc/inittab file. This file defines these important items for the init process:That the init process will restart What processes to start, monitor, and restart if they terminate What actions to take when the system enters a new run level Each entry in the /etc/inittab file has the following fields:id:rstate:action:process/etc/inittab fileentry descriptionThe following table describes the fields in an inittab entry. Field Description id Is a unique identifier for the entry. rstate Lists the run levels to which this entry applies. action Identifies how the process that is specified in the process field is to be run. Possible values include: sysinit, boot, bootwait, wait, and respawn.For a description of the other action keywords, see inittab4. process Defines the command or script to execute. /etc/inittab fileexample of defaultThe following example shows a default inittab file that is installed with the Solaris release. A description for each line of output in this example follows.ap::sysinit:/sbin/autopush -f /etc/iu.ap (1) sp::sysinit:/sbin/soconfig -f /etc/sock2path (2) smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog (3) p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/...(4)Initializes STREAMS modules Configures socket transport providers Initializes the master restarter for SMF Describes a power fail shutdown The init process is started and reads the /etc/default/init file to set any environment variables. By default, only the TIMEZONE variable is set. Then, init reads the inittab file and does the following:Executes any process entries that have sysinit in the action field so that any special initializations can take place before users login. Passes the startup activities to svc.startd. run level3 (multiuser with NFS)what happens when system is brought toFor a detailed description of how the init process uses the inittab file, see init1M.