Solaris 10

SMF

Service Management Facility

It is a core component of Solaris 10 It is part of the Predictive Self-Healing utilities in Solaris 10 SMF introduces changes to the Solaris administrative model SMF simplifies system & application services management

SMF Administrative Model

SMF services have an advertised state Failing services are automatically restarted when possible It offers simple utilities to manage services Administrators can permanently disable a service It supports relations between services It is also possible to define dependencies between services

Enabling and disabling services

Old method
mv /etc/rc2.d/S75cron /etc/rc2.d/x.S75cron

SMF method
svcadm disable system/cron:default

edit /etc/inet/inetd.conf (uncomment the finger line)

svcadm enable network/finger:default

Solaris services
Service: persistent program that handles system/user requests Services are not associated with any user login SMF Service is any long-lived SW object with:

- a well defined state - start and stop capability - relationship to other services (restart relationship) The building block of SMF is the service instance Every SMF service can have multiple instances

Restart relationship
Relationship between a service, its processes, and another service that is responsible for restarting the service It permits re-starters to identify cause of a service process failure

SMF then informs the appropriate re-starter

The re-starter decides upon corrective action:

- disable the service (maintenance mode) if defective - restart it automatically

Failure reasons: administrator error, failure of dependent service, SW bug, or underlying HW failure

SMF: Configuration Sharing

Service instance properties are represented by instance objects Service instance objects are children of Service objects Service instances properties are inherited by service objects An instance can override properties of parent service object SMF extracts configuration properties from service instances

FMRI: Fault Managed Resource Identifier

Identifies manageable service instances (fault/resource mgmt) SMF adapted services: FMRI strings prefixed with "svc FMRI consists of three components: category/name: instance svc:/ericsson/eric_3pp/versant:default SMF allows unique abbreviated FMRI forms Commands accept abbreviated FMRI if no ambiguity exists

Legacy services
Not all system services have been converted to use SMF

Traditional Solaris re-starters are maintained (/etc/rc*.d, etc/init.d & etc/inittab)

Legacy services are not restarted by SMF if they are stopped At failure they should be stopped/started by the re-starters

Legacy services can be only observed with SMF

Appear with an FMRI based on the path name of their rc-script

SMF re-starter
svc.startd is the default SMF re-starter

Restarts SMF adapted services if needed

At boot this new daemon will: - start the legacy rc scripts - start almost all SMF managed services (if their criteria met) Services are started up in parallel by default

SMF: Service Log Files

Re-starters may specify a log file to capture service information svc.startd logs actions to each services log file /var/svc/log e.g. SVC log for CRON: /var/svc/log/system-cron:default.log Service log file indicates: - when it was started - whether it started successfully - any messages printed during its initialization

Services started prior to the single-user milestone log under: /etc/svc/volatile

Log files associated with execution of the service are different (e.g. /usr/sbin/cron).

Service instance states

Legacy run: legacy service observable but not SMF managed Un-initialized: initial state for all instances before their configuration has been read by SMF Disabled: the instance is not enabled and is not running Offline: enabled, but not yet running or available to run Online: enabled and successfully started Degraded: enabled, but running at a limited capacity Maintenance: instance has encountered unrecoverable error

SMF manifests (I)

XML file that stores relationship and dependency information Also describes conditions when failed services can be restarted A separate manifest is required per service Sun provides default service manifests User can customize them or write own manifests User can get an empty template from Sun

Manifest files are stored in /var/svc/manifest SMF uses manifests to: - manage services - to determine root causes of service failures

Service Configuration Repository (I)

It is a persistent storage for: - Configuration information for SMF services - Runtime data for SMF services It is an SQL DB It should only be queried and manipulated with SMF commands It is controlled by svc.configd (/etc/svc/repository.db) Information is stored: - in local memory (volatile, for transient data: lock files, log files) - local files (persistent service description read from manifests)

Service Configuration Repository (II)

It provides a snapshot of each instance's configuration Snapshot is taken at the service instance successful start up It allows the service to be restored to a known configuration Changes in repository affect the service instance at refresh (refresh subcommand on the svcadm)

Manifest files are the source of configurations in the repository Configurations then configure all service objects instances

SMF milestones
Milestones supplants the traditional concept of run levels Run level: set of services necessary for one or for multiple users to log in the machine console (run level S, 2&3) These system states are represented in SMF as milestones Milestone: stable service representing a group of other services "svcs -d" lists services required for a milestone to be reached svcadm is used for setting the system's default run level (based on the FMRI of a valid milestone)

SMF Commands
svcadm: enable, disable and restart services svcadm allows to stop a service without its processes restarted

svcs: Shows state of services

svccfg: Configures the Service Configuration Repository

SMF in OSS-RC
Start order: Standard Solaris services 3PP services TBS SSR SSR Process Supervisor will then start all OSS MC The start order of the MCs is defined in DMDB (Prior to R5.2. it was in the PASDB, now removed)