Nuts And Bolts OpenSolaris SMF Lead image: Steve Cukrov,
Steve Cukrov,

Service Management Facility (SMF) in OpenSolaris

Skillful Service

Linux and OpenSolaris have a number of differences. For example, OpenSolaris uses a version of the legacy System V Init to start and stop system services automatically. By Harald Zisler

For most Linux admins, it is a matter of course to type /etc/init.d/ and then press the Tab key to start or stop a service. On (Open)Solaris, this is handled by the Service Management Facility (SMF), which manages the background processes (daemons), among other things, thus replacing the legacy RC scripts that are familiar to Linux users. However, its functionality goes further. SMF also handles devices and milestones – that is, services derived from runlevels.

SMF supports standardized management tasks, such as starting and stopping services and handling errors. For this to happen, the Fault Management Resource Identifier (FMRI) identifies a service on the system. The service and instance name are passed to the FMRI as follows:


In the following example,


/network/login refers to the service and rlogin to the service instance. The details always start with svc:. The svc.startd daemon is the master process that starts and restarts the operating system. Services are assigned to the following categories:

This classification is important for administrators who install applications outside of the package management system and want to use SMF to manage them. Each service entered here is also automatically assigned a status (see Table 1).

Tabelle 1: Service Status




Service enabled and successfully started


Service enabled but not started


Service enabled but started with limited resources


Service enabled but an unknown error occurred at start time


Initial status of all services before parsing the configuration

legacy run

Started via a legacy RC script – can only be monitored by SMF


Service is disabled and not running

OpenSolaris administrators can store the RC scripts in /etc/init.d with symlinks to the corresponding runlevel directories (/etc/rc.Runlevel.d). Starting at boot time and manual starting work in the normal way. The SMF tools list processes started in this way in the format lrc:/etc/RC-directory/RC-script.

Runlevels and Milestones

OpenSolaris still uses classic runlevels, and you can use init Runlevel or type a command (e.g., reboot) to change the runlevel or restart or shut down the system like any other Unix-style operating system. Like runlevels, milestones identify a defined state of active or inactive services (Table 2). Some of them are identical to runlevels. However, the manual (still) advises against using SMFs to replace previous runlevel handling, although it would be possible in some cases.

Tabelle 2: Runlevels and Milestones





Shut down system without powering off



Single-user mode with partially mounted filesystem


Like s, root login only



Multiuser mode, all services started except NFS



Like 2, but with NFS


Another multiuser mode for some extensions


Shut down and switch off the system


Reboot the system

The default runlevel is 3, and the default FMRI is milestone:/multi-user-server:default. To discover the current runlevel, use /usr/bin/who -r:

/usr/bin/who -r
. run-level 3 Jan 22 19:07 3 0 S

In this example, the current runlevel is 3. The command gives this information twice, along with the time the system entered the current runlevel. The details that follow indicate how often this runlevel was reached since the last reboot (0 times) and what the previous runlevel was (S).

Service for Services

SMF uses the SQLite database for management purposes. The administrator does not need to manipulate the database directly; instead, the following tools are available:

Hands-On: Status Query

As an example, I will discover the status of rlogin. Two query tools help with this: vp-services and svcs. On the Gnome desktop, which is installed by default, you can launch the vp-services tool via System | System management | Services. When the program launches, it lists the system services. The display can be sorted in ascending or descending order by clicking the column header. The filter function restricts the number of services displayed. Figure 1 shows the search function.

vp-services status query details. A mouse click selects the required line, following which, more services can be called (depending on the status, Enable, Disable, Properties).
Figure 1: vp-services status query details. A mouse click selects the required line, following which, more services can be called (depending on the status, Enable, Disable, Properties).

The shell command typically returns the results more quickly. If you call svcs without any parameters, the tool gives you a brief list of service names (svcs Service); the -l option provides more detailed information. The -xv option gives an exhaustive list of all services that are enabled but not running and, thus, possibly preventing other services from starting (Figure 2). The tool also outputs brief hints as to why the service failed to start and might point to references for further action. If you additionally specify a service name with the query, you are given more details, independently of the status. Figure 3 shows talkd in disabled then enabled mode.

List of services that failed to start.
Figure 2: List of services that failed to start.
Details of the talk service.
Figure 3: Details of the talk service.

Daemons launched by legacy RC scripts are displayed in part – for example, svcs without any options or with -a (Listing 1).

Listing 1: Display of Legacy RC Script

01 $ svcs -a | grep lrc
02 legacy_run 11:43:11 lrc:/etc/rc2_d/S20sysetup
03 legacy_run 11:43:11 lrc:/etc/rc2_d/S47pppd
04 legacy_run 11:43:11 lrc:/etc/rc2_d/S72autoU
05 install
06 ...

To discover the matching FMRIs, use the -p switch (Listing 2).

Listing 2: Matching FMRIs

01 svcs -p ssh
02 STATE         STIME           FMRI
03 online        11:43:10        svc:/network/ssh:default
04               11:43:10        500 sshd

Note that an FMRI displayed as online might not have created any processes. Some daemons are not launched until requested by inet.d.

Enabling and Disabling Services

The svcadm and vp-services tools are used to enable services. In the GUI-based program, you simply select the required line in the overview, possibly after a search, and then press Enable. Disabling follows the same steps, but the button is labeled Disable.

To launch a service, use the svcadm command with enable, and to stop it, use disable (Figure 4).

Enabling the talk service with svcadm.
Figure 4: Enabling the talk service with svcadm.


If something goes wrong when you try to enable a service, some troubleshooting is inevitable. As an example, I will enable talkd after hiding the executable. The FMRI changes to the maintenance state. Once you have fixed the problem, you can inform the system with the svcadm command with clear. The service will then start.

Calling svcs -xv service returns extended information on the service as described earlier. The same thing happens if you select the line with the service in the vp-services program and then press Properties.

svcadm mark service lets you switch a service to the maintenance stage manually. This prevents an automatic start when you change the runlevel or reboot. In the case of major reconfiguring, restoring, or updating, for example in database management, this is useful.


Service management in (Open)Solaris is vastly different from Linux; however, the clear service structure and the matching tools make it easy to find your way around.

Whether you prefer hacking at the command line or clicking buttons in a front end, you will find tools to suit any taste.