What makes OpenSolaris interesting? Reason #2: SMF

This is a #2 part in a series of posts about what makes OpenSolaris interesting (you can read reason #1: ZFS here). We'll go through different technologies and features that make OpenSolaris a compelling operating system.

Reason #2: SMF

SMF stands for Service Management Facility. It's a new way of managing system services (well introduced in Solaris 10 so it's not bleeding edge anymore), better than the original rc.d scripts which are still being used in Linux. Rc.d scripts are various scripts that are executed during system startup and shutdown and are located in /etc/rc.d, /etc/rc.\* and /etc/init.d directories. At first let's look at the problems that the old "rc.d" way has:

1. No reasonable way to handle dependencies - the only way you can define the sort-of-dependencies is by specifying numbers in the names of the script. This way you can say that script #1 is executed before script #2. But you can't really define multiple dependencies and if one script fails, there's no easy way to prevent some other process from starting if it depends on the script that failed.

2. Services need to be started sequentially - they cannot be started in parallel (because of the awkward way of specifying dependencies).

3. Services don't get restarted automatically - if a service fails there exists no process to check if it failed or attempt to start it again - if you want this kind of functionality you need to write it yourself or search for some other tool.

4. Creating new services requires lots of shell hacking - what people usually do is they copy the existing script and update it as they need. This process can easily lead to hidden errors.

5. Monitoring of services is hard - e.g. if a service fails you often don't know about it until you check the status of the process - but there's no easy way to map the service name to a process ID - you need to know which process was started by the service (which can be found out by parsing the shell script which may not be the most pleasant thing to do).

6. Maybe I forgot some other problems rc.d scripts have, but I can say in general it's an old architecture that doesn't satisfy requirements for high availability and observability that current systems have. Which is why SMF was created.

So what is SMF?

SMF is a replacement of rc.d (startup/shutdown) scripts but it solves more than that - it solves the whole problematics of managing services.

1. It can handle service dependencies - you can declare how services depend on each other. Multiple dependencies are possible.

2. SMF enables parallel starting of services, because we know their dependencies. This can lead to faster start of services in case you have many services to start.

3. If a service fails it is possible to restart it - there is a service called the restarter which monitors services for you and attempts to restart them if necessary. You can control the number of attempts for restart or if you want to attempt restarting at all.

4. SMF has centralized configuration - all configuration is done using simple XML files which have well known structure.

5. Observability - you can easily list all services, find out info about individual services, list failed services (including links to log files which helps you find out quickly what went wrong). You can find out process IDs of processes managed by the service easily.

6. It is easy to "SMF-ize" your application - you just need to create the XML configuration file and import the service.

7. SMF can handle legacy "rc.d" type services. Of course it can't provide as much control and information about them but you can still use old rc.d scripts if you need to.

8. Much more - again I am probably forgetting some other advantages (e.g. having fully qualified names of services, milestones which define different levels during startup, etc.) - you'll find more advantages in the documentation.

Here are some useful commands when working with SMF:

Listing all services:

$svcs

Listing failed services:

$svcs -x

Detailed information about a service (FMRI is the Fault Management Resource Identifier which identifies the service):

$svcs -v FMRI

Showing process IDs related to a service:

$svcs -p FMRI

Finding restarter for a service:

$svcs -l FMRI

Enable a service:

$svcadm enable FMRI

Disable a service:

$svcadm disable FMRI

There is a nice article on the O'Reilly site I recommend to read about SMF: Using Solaris SMF. Even though the article was written for Solaris, the listed commands also work in OpenSolaris. It's a good reading if you want to get started with using SMF.

Comments:

Most of the time I use linux, and my flavour of choice is gentoo. In Gentoo the init used is sysvinit and the initscripts is handled by openrc, which handles multiple dependencies well and allows parallell startup. The script is also separated from the config: in /etc there is both init.d/ and conf.d/. The scripts in init.d/ have all config options in there conf.d/ counterpart. Very nice, and much more readable than an xml-file imho.

openrc also makes it easy to see status of all services started. It does not automaticly restart a failed service, so there SMF has an advantage.

All in all SMF has some nice points, but there are linux alternatives out there which provides almost the same functionality.

Posted by Andreas Nilsson on August 11, 2008 at 11:09 AM GMT #

Thanks for sharing, glad to know there's an alternative in Linux (I use Linux as well :)

Posted by Roman Strobl on August 11, 2008 at 01:15 PM GMT #

Thanks for the link, Roman.

There's 2 points you might want to add to your arguments on SMF.

1. Configuration data for a running service is actually stored in a SQLite database, after it gets imported from the XML file. Using the "svcprop" command, you can make configuration changes to a service. If you make a mistake, you can revert back to a previous known working snapshot.

2. Using extended privileges, it's possible to harden a service, or give it slightly elevated privileges without having the program ever run as the root user. You can also have specific non-root user accounts restart the service.

Posted by Chris Josephes on August 11, 2008 at 02:29 PM GMT #

@Chris - the priviliges stuff deserves to be its own 'what makes opensolaris interesting', Solaris RBAC is excellent.

In fairness to Linux (as @Andreas says), the rc system is being phased out on some distros, which solves some of its clankier failings. runit is a drop-in replacement that looks promising : http://smarden.org/runit/

Posted by Dick Davies on August 12, 2008 at 02:02 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.

Connect with Oracle Solaris:


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today