Table of Contents

Introduction to SMF

The service management facility (SMF) is the Solaris way to start and stop servers (web, database, email, et cetera). SMF is cool for two reasons:

  1. It monitors running services and restarts them automatically if there is a problem.
  2. It understands the dependencies between services. For example, there is no point in starting your webserver if your network is not running.

SMF consists of three command line utilities:

svcs : Examine service status

This command displays information about the state of your services: whether or not they are running and any problems encountered in starting them. In general, services will fall into three different states:

The command

svcs

with no arguments displays a list of all enabled services (online and maintenance).

svcs -a

displays a list of all online and offline services. By default svcs prints out the current state of the service (STATUS), when the service entered the current state (STIME), and the name of the service (FMRI).

Each service is described by a name called an FMRI (fault management resource identifier). For example, the FMRI for Apache is svc:/network/http:cswapache2.

$ svcs svc:/network/http:cswapache2
STATE          STIME    FMRI
disabled       May_31   svc:/network/http:cswapache2

This shows that Apache was disabled on May 31st.

Since FMRIs are rather long, you can also write them in short form

$ svcs network/http:cswapache2
$ svcs http:cswapache2
$ svcs http
$ svcs cswapache2

These four commands all return the same information about Apache. Sometimes you might not know the exact name of the service, so it is often useful to use grep in combination with output from svcs -a.

$ svcs -a | grep -i mysql
enabled       May_31   svc:/network/cswmysql5:default

showing that the MySQL service is referred to as cswmysql5 (version 5 installed with blastwave).

Why SMF is wonderful

(adapted from HOWTO: Solaris SMF & Startup Scripts)

When SMF starts a service it has a “contract” for that service. The contract keeps track of what processes are running for any given service. Using the ”-p” option we can see what processes are part of a service's contract.

$ svcs -p network/cswmysql5
STATE          STIME    FMRI
online         16:55:27 svc:/network/cswmysql5:default
             	   16:55:27    28938 mysqld_safe
             	   16:55:27    29004 mysqld

Here we see that the mysql daemon is process number 29004. Let's try killing it.

$ kill -9 29004
$ svcs -p network/cswmysql5
STATE          STIME    FMRI
online*        17:00:01 svc:/network/cswmysql5:default
             	   16:55:27    28938 mysqld_safe
             	   17:00:01    29228 mysqld
$ mysql -u mysql
...
mysql> \q
Bye

Even though mysqld was brutally killed it was automatically restarted. Notice that the STIME shows that the mysql has just gone back online. The asterisk (“online*”) indicates that the service is currently in a transition state, although you can see that MySQL is already back in action by the time the next command was run.

But SMF isn't restarting the service in brain-dead mode like a legacy inittab: we can define thresholds regarding restarts. For instance, if SMF restarts a service more than 3 times in 60 seconds, something is probably very wrong and it should stop attempting it. At that point SMF will put the service in a “maintenance” mode, and it will stay that way until you clear the state with svcadm clear /some/fmri/service/name.

svcadm - Start and stop servers

This command is used to issue instructions to start, stop, restart, or refresh servers.

$ sudo svcadm enable cswmysql5

starts MySQL. We now see that the service is enabled:

$ svcs cswmysql5
STATE          STIME    FMRI
online         15:20:39 svc:/network/cswmysql5:default

You stop services with

$ sudo svcadm disable cswmysql5

After you have made a configuration change (to httpd.conf, for instance), you can refresh an enabled service with

$ sudo svcadm restart cswapache2

if you would like a non-sudo capable use to be able to manage SMF you can modify the users profile as follows

Edit /etc/user_attr and add:

myuser::::profiles=Service Management

(replace myuser by your login) then myuser becomes able to manage SMF (import, stop, start…) without being a sudoer.

This is a more secure solution than giving out more sudoers access than is necessary.

svccfg - Configure services

Forthcoming

  1. Customizing manifests and writing your own
  2. Manifest recipes (mongrel, postgres, nginx).

Determining what's wrong

Forthcoming

  1. Examining why services have failed (svcs -x and /var/svc/log)
  2. Restarting services after the problem has been corrected (svcadm clear)

References