Sunday January 30, 2005

Putting Tomcat under SMF

I had brought up the topic of running Tomcat in a zone for students in an educational setting. While not required, it would be nice if Tomcat played nice with the Service Management Facility (SMF). Plus, I'll be doing booth duty talking about Solaris 10 at the AFCEA West 2005. I figure a SMF demo there showing how to integrate existing applications might come in handy. Now, if you really want to learn about SMF, go to those who know much more than me.

While I understand what the benefits of SMF are, this was my first attempt at actually SMF-enabling an application. It's actually pretty easy at an abstract level when you leverage "man smf" and some of the devloper documentation. Another helpful task is to read the actual service description dtd (/usr/share/lib/xml/dtd/service_bundle.dtd.1). Unfortunately the developer documentation doesn't go into much detail yet, but the folks bringing you SMF were working on hard on getting the actual bits out. Expect more documentation to be on it's way.

Here's the net effect of putting Tomcat under SMF control from a lifecycle perspective with some notes:

# svcs tomcat
svcs: Pattern 'tomcat' doesn't match any instances
STATE          STIME    FMRI

Note that SMF has no idea about a Tomcat service out-of-the-box. The first step is to create a service descriptor and import it as follows:

# svccfg import ./tomcat.xml
# svcs tomcat
STATE          STIME    FMRI
offline*       13:27:04 svc:/application/tomcat:default

The service descriptor has been imported and we check the status of the service using "svcs tomcat". You'll note that it's state at this point is "offline*". What this means is that SMF is in the process of starting the service.

# svcs tomcat
STATE          STIME    FMRI
offline*       13:27:11 svc:/application/tomcat:default

Still waiting ...

# svcs tomcat
STATE          STIME    FMRI
online         13:27:16 svc:/application/tomcat:default

Cool, now it's running. One of the semantics of starting a service in SMF is that the application/script that glues the application into SMF has to check to ensure that the service is *really* running. It's no rc.d fire & forget here. I chose to use /usr/sfw/bin/wget as a simple means to check that Tomcat was really up and running before returning a "SMF_OK" value. Now lets check to see what services Tomcat depends on. In the Tomcat service descriptor, I defined required dependencies such that if any of the services Tomcat depends on is offline, Tomcat will be offlined. Here's those dependencies:

# svcs -d tomcat
STATE          STIME    FMRI
online         13:21:55 svc:/network/loopback:default
online         13:22:09 svc:/network/physical:default
online         13:22:21 svc:/system/filesystem/local:default

That's simple. If the loopback, physical or local filesystem are not online, Tomcat either will not start or will be offlined. Now let's see what services depend on Tomcat:

# svcs -D tomcat
STATE          STIME    FMRI

None. I knew that :) Now let's disable the physical network interface and see what happens:

# svcadm disable physical
# svcs tomcat
STATE          STIME    FMRI
offline        13:27:50 svc:/application/tomcat:default

Since the physical interface was manually disabled and Tomcat has a required dependency on that interface, SMF automatically offlines Tomcat. Let's say we didn't know that the physical interface was disabled and we wanted to know why Tomcat was offline. How is that "debugged"? Simple "svcs -x":

# svcs -x tomcat
svc:/application/tomcat:default (Tomcat)
 State: offline since Sun Jan 30 13:27:50 2005
Reason: Service svc:/network/physical:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
Impact: This service is not running.

Cool. Now to fix the problem:

# svcadm enable physical
# svcs tomcat
STATE          STIME    FMRI
online         13:28:16 svc:/application/tomcat:default

Now that was a fun exercise, wasn't it? So what is the point of all this? Now we don't have this very odd and outdated means of dealing with service lifecycles and inter-relationships in Solaris. There are clean relationships and dependencies between services. If you want to see a neat view of boot ordering and bootup times, check out what Dan Price and Eric Schrock have done, leveraging the work done at bootchart.org

(2005-01-30 14:30:45.0) Permalink Comments [7]