SMF

Introduction :
In most Unix environments, the startup process consists of a autonomous boot scripts. They act independently of one another; unaware of what scripts have already run or which ones will run after them. When they are invoked, there is no serious error checking and no recourse if the script fails. For Solaris 10, Sun introduced the Service Management Facility. SMF is a framework that handles system boot-up, process management, and self-healing. It addresses the shortcomings of startup scripts and creates an infrastructure to manage daemons after the host has booted.

A Unix host will start the sendmail daemon with the script S80sendmail from either the /etc/rc2.d or /etc/rc3.d directory. When S80sendmail runs, it won't be aware of any previous problems such as a NIS failure or /var never properly mounting. You could write tests into the script, but that increases startup time and the complexity of each script. In the SMF environment, sendmail is a service. Solaris 10 defines a service as a persistent program that handles system or user requests. Services are expected to be fault tolerant and manageable by the operating system. Services are identified by a Fault Management Resource Identifier. The FMRI is broken up in a category hierarchy to help identify the service and what it is responsible for.

Here is the FMRI for sendmail, ssh, and other services running on a host: svc:/network/smtp:sendmail svc:/network/ssh:default svc:/network/system/filesystem/local:default lrc:/etc/rc2_d/S99audit Here is the breakdown of the FMRI structure: Schema servicename svc: /network svc: /network svc: /network lrc: /etc instance /smtp /ssh /system/filesystem/local /rc2_d category :sendmail :default :default S99audit

The service names usually include a general functional category. The categories include the following: application device milestone network platform system

Services in the SMF environment start up in parallel, but each service will become available only when all its listed dependencies are. This means the host will have a faster boot-up, and it will reduce the chances of a cascading failure of services. There is no explicit order to service startup, so sendmail or its dependencies could start up at any time. Almost all services under the SMF are controlled by one service known as the restarter. The restarter controls the svc.startd daemon, which in turn starts the other services, tests their dependencies, and restarts them if they fail. When Solaris 10 boots up, svc.startd is one of the first programs spawned from /sbin/init. It's still possible to use rcN.d scripts under Solaris 10; however, the programs started from these scripts will not be under SMF control. These are referred to as legacy

run scripts. They have an FMRI, like normal services do, but the schema prefix is lrc:.
Legacy run scripts are not initialized until all SMF services are up and running. When the host shuts down, they are the first stop scripts run before the SMF services are disabled.

Functions of SMF
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 services using svcs command. Allows for services to be enabled and disabled using svcadm either permanently or temporarily. 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 from the Open Boot prompt. Provides compatibility with rc scripts.

Changes in Behavior When Using SMF

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. The legacy services are started after the SMF services.

Service States
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 is enabled, but is running at a limited capacity. disabled The service 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 has encountered an error that must be resolved by the administrator. offline The service is enabled, but the service is not yet running or available to run. online The service is enabled and has successfully started. uninitialized This state is the initial state for all services before their configuration has been read.

SMF Manifests
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_bundle(4) 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 svccfg or inetadm man pages.

SMF Profiles:
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.

Service Configuration Repository :

The 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. The service configuration repository can only be manipulated or queried using SMF interfaces.

SMF Command-Line Administrative Utilities

inetadm Provides the ability to observe or configure services controlled by inetd svcadm Provides the ability to perform common service management tasks, such as enabling, disabling, or restarting service instances svccfg Provides the ability to display and manipulate the contents of the service configuration repository svcprop Retrieves property values from the service configuration repository with a output format appropriate for use in shell scripts svcs Gives detailed views of the service state of all service instances in the service configuration repository

Boot-up and Runlevels

Sun has enhanced the runlevel model with service milestones. In Unix, runlevel one is single user mode, two is multiuser mode, and three is multiuser mode with file sharing or network services. In each runlevel, there is a core set of services that must be brought online. For example, levels one, two, and three all require a minimum amount of local filesystems to be mounted, and network interfaces to be online. Runlevel two requires all internet services to be online, and users must be able to log on to the host. Runlevel three requires everything level two does, plus the ability to share files by NFS. Milestones are services that do have a dependent list of services. Once those services are online, the milestone is marked online. The milestone ensures an expected group of services are up and running, so you don't have to check each individual service.

Command to see the milestones currently online. $ svcs "svc:/milestone/*"

Solaris Run Levels and SMFMilestones

Run Level S 2 3 SMFMilestone FMRI milestone/single-user:default milestone/multi-user:default milestone/multi-user-server:default

When toUse Run Levels or Milestones

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.

Tasks:
1. Practice the commands. 2. Display the status of a service instance. 3. Display the service dependents. 4. Display the dependencies of a service. 5. Disable a service instance. 6. Enable a service instance 7. Restart a service instance. 8. Modify a service instance. 9. Convert inetd.conf entries. 10. Repair a corrupt service configuration repository. 11. Boot a system without starting any services. 12. Changing the milestones

13. Stop or start a service. 14. Add a run control script. 15. Disable a run control script. 16. Debugging a ServiceThat IsNot Starting