Wednesday, April 10, 2013

Service Management Facility

The Service Management Facility was introduced in Solaris 9 as an alternative way to manage services. In Solaris 10, SMF has been made the default way to manage most services. The SMF framework has significant advantages over the legacy SVR4 mechanisms, primarily in terms of service monitoring and integration with the Fault Management Facility.

Basic Commands

The basic commands for managing services under SMF (Service Management Facility) control are svcs, svccfg and svcadm. The man pages for these commands are a good source of detailed information.

inetadm can be used to monitor services under inetd control.

Many commands require referencing the service identifier, also known as an FMRI.


  • svcs -a: Lists all services currently installed, including their state.
  • svcs -d FMRI: Lists dependencies for FMRI.
  • svcs -D FMRI: Lists dependents for FMRI.
  • svcs -l FMRI: Provides a long listing of information about FMRI; includes dependency information
  • svcs -p FMRI: Shows relationships between services and processes.
  • svcs -t: This change is temporary (does not persist past a boot).
  • svcs -x: Explains why a service is not available.
  • svcs -xv: Verbose debugging information.


  • svcadm clear FMRI: Clear faults for FMRI.
  • svcadm disable FMRI: Disable FMRI.
  • svcadm enable FMRI: Enable FMRI.
  • svcadm refresh FMRI: Force FMRI to read config file.
  • svcadm restart FMRI: Restart FMRI.

To make configuration changes to a non-inetd service, edit the configuration file, then enter the svcadm restart command.


  • svccfg: Enter interactive mode.
  • svccfg -s FMRI setenv ENV_VARIABLE value: Set an environment variable for FMRI. Follow by svcadm refresh and restart commands.


  • inetadm -l FMRI: Displays properties for FMRI.
  • inetadm -m FMRI property_name=value: Set a property for FMRI.

In particular, the "exec" value for an inetd-controlled service is the command line executed for that service by SMF. It may be desirable, for example, to change this value to add logging or other command-line flags.

To convert an inetd.conf file to SMF format, run the command:
inetconv -i /etc/inet/inetd.conf

Service Identifiers

Services are identified by their FMRI. (This stands for Fault Managed Resource Identifier.) An example is:
Some commands do not require the full FMRI if there is no ambiguity.

Legacy init scripts have FMRIs starting with lrc. For example:

Converted inetd services have a syntax like one of the following, depending on whether or not they are rpc services:
svc:network/service-name/protocol svc:network/rpc-service-name/rpc_protocol

SMF Service Starts

The svc.startd daemon is the master process starter and restarter for SMF. It tracks service state and manages dependencies.

Services that are managed through init scripts can be added to SMF via the inetconv command. Such additions are only monitored for status, but other SMF facilities may not work.


If a service is in the maintenance state, first make sure that all associated processes have died:
svcs -p FMRI
Next, (for all processes displayed by the above):
pkill -9 PID
Consult the appropriate logs in /var/svc/log to check any errors; perform any needed maintenance.
Restore the service:
svcadm clear FMRI


The scripts that implement the startups and shutdowns are located in their usual place in /etc/init.d for the lrc services, or in /lib/svc/method for most of the other services.

Other locations may be specified for a particular service. To track down the script locations for a particular service, do something like the following:

# svccfg -s smtp
svc:/network/smtp> list
svc:/network/smtp> select sendmail
svc:/network/smtp:sendmail> list
svc:/network/smtp:sendmail> listprop *exec
start/exec astring "/lib/svc/method/smtp-sendmail start"
stop/exec astring "/lib/svc/method/smtp-sendmail stop %{restarter/contract}" refresh/exec astring "/lib/svc/method/smtp-sendmail refresh"

Boot Messages

Boot messages are much less verbose than previously. To get verbose output, boot with the
boot -v
boot -m verbose

svcadm can be used to change the run levels. The FMRIs associated with the different run levels are:

  • S: milestone/single-user:default
  • 2: milestone/multi-user:default
  • 3: milestone/multi-user-server:default
Run levels can be displayed with
who -r

SMF Profiles

SMF profiles are XML files in /var/svc/profile which list sets of service instances which are enabled and disabled.

Different SMF profiles can be used. They are stored in /var/svc/profile. To use a different one, perform the following procedure:
svccfg apply /var/svc/profile/desired_profile.xml

The local profile /var/svc/profile/site.xml allows local customizations. This profile is applied after the standard profiles.

To make a copy of the current profile for editing, run:
svccfg extract> profile-file.xml

Service Configuration Repository

Stores persistent configuration information and SMF runtime data for services.

Each service's manifest is in an XML-formatted text file located in /var/svc/manifest. The information from the manifests is imported into the repository through svccfg import or during a reboot.

This is covered in the svccfg, svcprodp, service_bundle and svc.configd man pages.

If the repository is corrupted, it can be restored from an automatic backup using the /lib/svc/bin/restore_repository command. The svcadm refresh; svc adm restart command will make a snapshot active. Automatic snapshots are taken for initial (import of the manifest), running (when service methods are executed) and start (last successful start).

Revert to a Snapshot

The procedure to revert to a snapshot is the following:
Run svccfg in interactive mode:
In the svc:> prompt, select the desired service with a full FMRI:
select FMRI
List the available snapshots:
Revert to the desired snapshot:
revert desired_snapshot_label
Quit out of the svccfg interactive mode:
Update the service configuration repository information:
svcadm refresh FMRI
svcadm restart FMRI

Boot Troubleshooting

To step through the SMF portion of the boot process, start with:
boot -m milestone=none
Then step through the milestones for the different boot levels:
svcadm milestone svc:/milestone/single-user:default
svcadm milestone svc:/milestone/multi-user:default
svcadm milestone svc:/milestone/multi-user-server:default

Several things should be examined if a service fails to start:

  • Is the service in maintenance mode? (svcs -l FMRI)
  • If so, why? Check the log file specified in the svcs -l FMRI | grep logfile output, and run svcs -xv FMRI
  • If the problem has been resolved, clear the fault with svcadm clear FMRI
  • Check for service dependencies with svcs -d FMRI The output from svcs -l distinguishes between optional and mandatory dependencies.
  • Check the startup properties with svcprop -p start FMRI The startup for the process can be trussed to get some visibility into where it is failing by inserting a truss into the start or exec statement for the service. To do this, just add truss -f -a -o /path/service-truss.out to the beginning of the start or exec statement with an svccfg -s statement.

No comments: