Leading in with my post on switching from Linux to OpenSolaris, there are quite a few things I am in love with on OpenSolaris.

Since my first real world exposure to OpenSolaris is the process of migrating web applications away from Linux, the first thing I really had to get familiar with is the Service Management Facility framework.  SMF for short.  SMF is the Solaris equivalent of UNIX/Linux init.d, Apple’s launchd, or Windows services.

I’m coming from a decade long Linux background so let me compare and contrast init.d and SMF.

  • Like init.d, SMF services are first-class objects that you can query for status and start and stop.
  • Unlike init.d, if SMF services encounter an error that caused a failure of the service, SMF will AUTOMATICALLY RESTART the service!  However, it isn’t a blind restart.  If the service fails after X number of restarts, SMF will disable the service until manual intervention happens.
  • SMF provides a facility to see why a service is not running or stats on running.  The command svcs -x (I remember using SerViCe Status):
[user@host ~]$ svcs -x tomcat
svc:/network/tomcat:default (tomcat)
 State: online since January  6, 2010  7:54:02 PM GMT
   See: /var/svc/log/network-tomcat:default.log
Impact: None.

Or for a disabled service:

[user@host ~]$ svcs -x tomcat
svc:/network/tomcat:default (tomcat)
 State: disabled since January  7, 2010  3:07:47 PM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: /var/svc/log/network-tomcat:default.log
Impact: This service is not running.

Notice the Reason field. Awesome!

  • Like init.d, SMF provides start/stop/restart actions on a service.  However, the equivalent actions are named differently: enable/disable/restart.  Use svcadm enable tomcat to start a service.
  • Unlike init.d, SMF provides the ability for non root users to start and stop services!
  • Like init.d, SMF provides a way for services to fire up in a dependent order.
  • Unlike init.d, SMF provides a way to declare those dependencies rather than relying on an integer value to start in a certain order.  On top of being much clearer to admin, this allows systems to boot up faster by starting services in parallel.
  • Unlike init.d, SMF provides a logging framework that is transparent to the service.  I’ve found in my use, this is both good and bad.  My SOLR SMF config is moving the SOLR log output from the SOLR install directory to the SMF log directory.  I’ll get to that in another post.
  • Unlike init.d, SMF is much more complicated then adding a simple shell script to the init.d folder.  The learning curve is a bit longer/higher than init.d.

This list is certainly not comprehensive.  You can find out more at Sun’s BigAdmin site.  Solaris Service Management Facility – Quickstart Guide

Up next, a SMF config for Tomcat…

About the Author:

Learned something? Great! Need help on your development project? I'm available for hire:

  • Ruby on Rails
  • iOS Development
  • System Architecture & Performance

Get in touch:

Discussion

No comments yet, be the first.

Leave a Comment