Service Management Facility (SMF)
, introduced in Solaris 10, enables a unified model for services and service management on each Solaris system. It is a core part of the Predictive Self-Healing technology available in Solaris 10, which provides automatic recovery from software and hardware failures as well as administrative errors.
One of my colleagues at Sun, Bob Netherthon, has a very nice slide deck on SMF here.
Since many of our customers asked, I have created a basic service manifest and simple instructions for WebSphere Application Server (WAS) as an example.
- Put the service manifest file named "was61.xml" to a temporary directory /tmp.
- Put the service method file named "svc-was61" in /lib/svc/method/svc-was61.
- Edit this service method file to reflect the correct WAS path information, etc.
Follow the steps below.
bash-3.00# chmod 755 /lib/svc/method/svc-was61
bash-3.00# svccfg import /tmp/was61.xml
bash-3.00# svcadm enable was61
bash-3.00# svcs -l was61
name WebSphere Application Server v6.1
state_time Thu Jun 14 18:23:17 2007
dependency require_all/error svc:/milestone/network:default (online)
dependency require_all/none svc:/system/filesystem/local:default (online)
dependency optional_all/error svc:/system/filesystem/autofs:default (online)
Once you do "svcadm enable was61", WAS should start if the configuration is valid. The log file is located at: /var/svc/log/application-was61:was_server1.log.
If the service need to be removed, do the following:
bash-3.00# svcadm disable was61
bash-3.00# svccfg delete was61
Note that in the manifest, the exec_method was defined using the service method (e.g. external shell script: exec="/lib/svc/method/svc-was61 start"). This could be a WAS command itself (e.g. exec="/opt/IBM/WebSphere/AppServer/profiles/AppSvr01/bin/startServer.sh start"). The service method is a good way to separate the WAS start up/shutdown commands because if you need to change the profile or WAS location for this application service, you just need to modify in the service method script rather than having to re-configuring the service manifest.
In the case you have multiple WAS profiles, applications or versions, this manifest can also be used as a template to create new service manifests (e.g. was61_tradeapp1, was602_storeapp1, etc.).
You can also add other dependencies in the service manifest that the WAS services rely upon (e.g. another standalone application that your application requires to be co-located on the same system or a JMS provider that must be started before the WAS services, etc.).
Another good practice is to have the WAS processes to be started by a non-root user, which you can configure accordingly like this example for Apache.
Best of all, look at OpenSolaris website for:
Finally, you should include useful and concise comments in the service manifest and methods for ease of maintenance.