Service Management Facility (SMF) brings a complete pack of Solaris service configuration and management in a very sorted manner which is accurate and can be interacted simply with Solaris 10. SMF starts services in parallel, according to the dependencies, which allows the system to boot faster and reduces dependency conflicts while using the services.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
Why is SMF used?
[/symple_box]

SMF provides centralized configuration database structure for managing and interacting with system services.

• A mechanism to establish and formalize dependency relationships between services.
• Information on procedures to start, stop, and restart services.
• This centralized database helps in providing information on startup and automatic restart of services and gives status.
• A structured mechanism for Fault Management of system services (FMRI).
• Detailed information about misconfigured services such as an explanation of why a service is not running.
• Individual log files for each services in /var/svc/log.
• Facilitates service dependencies. (A and B are depended to each other)
• Decides the order of the services to be started so the services run parallelly.
• Provides legacy rc scripts support so that old programs will work otherwise will have to add service config database.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
Features of SMF.
[/symple_box]

• Service configuration database.
• Process restarter.
• Administrative CLI utilities.
• Support Kernel functionalities.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
List of Service Identifiers
[/symple_box]

Each service instance has a Service Identifier. The service identifier forms the FMRI and indicates the service type or category, name and instance.

The service includes

• application
• device
• legacy
• milestone
• network
• platform
• site
• system

Example of service instance FMRI is

[symple_box color=”gray” text_align=”left” width=”100%” float=”none”]

svc:/system/svc/restarter:default

svc = shows the service is managed by SMF

system =  is the category of service

svc = service itself

restarter = is the instance of svc service

default = the first instance of the service.

[/symple_box]

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
Service States
[/symple_box]

You keep the service in various states like online, offline, disabled/uninitialized and legacy_run/maintenance/degraded mode.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
Milestone
[/symple_box]

It is the set of defined services which depended on other services. Which makes the system states services requires a defined set of services to be running. Currently there are seven milestones like single-user, multi-user, multi-user-server, network, name-services, sysconfig, devices.

[symple_box color=”gray” text_align=”left” width=”100%” float=”none”]

bash-3.2# svcs | grep milestone

online          0:03:26 svc:/milestone/name-services:default

online          0:03:39 svc:/milestone/network:default

online          0:03:40 svc:/milestone/devices:default

online          0:03:42 svc:/milestone/single-user:default

online          0:03:49 svc:/milestone/multi-user:default

online          0:03:50 svc:/milestone/multi-user-server:default

online          0:03:54 svc:/milestone/sysconfig:default

[/symple_box]

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
The svc.startd Daemon
[/symple_box]

The svc.startd daemon is responsible for maintaining the system services. The svc.startd daemon ensures the system boots at appropriate milestones. Thus by booting the milestone at single-user, multi-user, multi-user-server. Since svc.startd daemon is responsible for ensuring the correct running, starting and restarting of service system it is also called master restarter.

[symple_box color=”gray” text_align=”left” width=”100%” float=”none”]

bash-3.2# ls -ltr /var/svc/manifest/milestone/

total 36

-r–r–r–   1 root     sys         2279 Jan 22  2005 multi-user-server.xml

-r–r–r–   1 root     sys         1467 Jan 22  2005 network.xml

-r–r–r–   1 root     sys         1796 Jan 22  2005 name-services.xml

-r–r–r–   1 root     sys         3048 Jan 22  2005 multi-user.xml

-r–r–r–   1 root     sys         1491 Jan 22  2005 sysconfig.xml

-r–r–r–   1 root     sys         3706 Jan 22  2005 single-user.xml

-r–r–r–   1 root     sys         1437 May 21  2009 patching.xml

[/symple_box]

You can see files which describe the dependencies for the milestone.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]
The Service Configuration Repository
[/symple_box]

This repository database stores information and configuration about the state of each service instance. The repository is divided into memory and disk based local files.

This file can only be manipulated using the SMF interface utilities svccfg and svcprop. The repository file is manages by svc.configd daemon. The disk-based database is /etc/svc/repository.db. The repository is managed by the svc.configd daemon. The svc.configd daemon backs up the repository before applying any changes issued by the SMF commands and utilities. These backup copies of the repository ensure that fallback is possible. A corrupt repository prevents the system from booting. A corrupt repository can be repaired by booting the system to single-user, and running the command:

[symple_box color=”gray” text_align=”left” width=”100%” float=”none”]
# /lib/svc/bin/restore_repository
[/symple_box]

[symple_divider style=”solid” margin_top=”20px” margin_bottom=”20px”]

[symple_box color=”gray” text_align=”left” width=”100%” float=”none”]

If you like the blog please follow us [icon name=”icon-facebook”] [icon name=”icon-twitter”] [icon name=”icon-google-plus-sign”]

[/symple_box]