Putting Tomcat under SMF
By John Clingan on Jan 30, 2005
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:defaultNow 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