Skillful Service

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:

svc:/Service:Instance

In the following example,

svc:/network/login:rlogin

/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:

• Application
• Milestone
• Platform
• Device
• Network
• Site
• System

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).

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.

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:

• svcadm manipulates service instances (start, stop, ?).
• svcs is a service status query.
• svccfg configures services.
• svcprop is a shell script query.
• inetadm manages services not controlled by inetd.
• vp-services is a graphical administrator tool with svcadm and svcs functionality.

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.

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.

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

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).

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).

Troubleshooting

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.

Conclusions

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.