What makes OpenSolaris interesting? Reason #2: SMF
By Roman Strobl on Aug 11, 2008
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:
Listing failed services:
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.