Adding environment variables to an SMF service

I create an SMF manifest last week for a new service, and needed two environment variables to be set prior to the services’ start method being invoked. After poking around the svccfg manual page, I came across the setenv subcommand, which can be used to set an environment variable:

$ svccfg -s tinydns setenv FOO bar

Since I was creating a manifest from scratch, I ran this against a temporary service and then used the svccfg “export” command to display the entry I needed to add to the manifest I was creating:

$ svccfg export tinydns

Here is the XML that was displayed for the environment variable addition:

<exec_method name=’start’ type=’method’ exec=’/lib/svc/method/tinydns start’ timeout_seconds=’60’>
<envvar name=’FOO’ value=’bar’/>

I like SMF, but sometimes wonder if it is over-engineered for what it actually needs to do. If you have opinions on this, please let me know by submitting a comment.

Speeding up the initial SMF manifest import

If you are an avid Solaris 10 user, you may have noticed that it takes a bit of time for global and non-global zones to initialize after they are installed. One of the issues that slows down the initialization process is the initial manifest import, which is a series of steps that takes place to populate the repository with one or more service manifests. The enhanced profiles project is currently tasked with permanently addressing this issue, but Steve Peng just putback CR #6351623 (Initial manifest-import is slow) to provide some temporary relief. This is good stuff, and I can’t wait to get my hands on Nevada build 84 to see just how well his tmpfs solution works! If anyone has tested Steve’s solution, or copied over their own repository during system initialization, please leave a comment or shoot me an email. I am curious to see just how speedy these solutions are!!

The power of the SMF Apache2 service

I am in the process of migrating some old Solaris 8 web servers to Solaris 10, and plan to use SMF to stop and start Apache. Solaris ships with a relatively recent release of Apache (if only it included the LDAP authentication module and PHP), which is nicely integrated with SMF. If your a *NIX admin, you gotta love the fact that SMF will restart processes for you:

$ svcadm enable apache2

$ ps -ef | grep http

webservd 16663 16660   0 09:57:59 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16662 16660   0 09:57:59 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16661 16660   0 09:57:59 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16664 16660   0 09:58:00 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16665 16660   0 09:58:00 ?           0:00 /usr/apache2/bin/httpd -k start
    root 16660     1   2 09:57:58 ?           0:00 /usr/apache2/bin/httpd -k start

$ pkill httpd

$ ps -ef | grep http

webservd 16689 16686   0 09:58:08 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16690 16686   0 09:58:08 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16691 16686   0 09:58:08 ?           0:00 /usr/apache2/bin/httpd -k start
    root 16686     1   2 09:58:07 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16688 16686   0 09:58:08 ?           0:00 /usr/apache2/bin/httpd -k start
webservd 16687 16686   0 09:58:08 ?           0:00 /usr/apache2/bin/httpd -k start

Configuring SMF services to write to the console during boot

I like several things about the Solaris service management facility (SMF), but one thing I don’t care for is SMF redirecting the output from startup scripts to logfiles in /etc/svc/volatile and /var/svc/log. Call me old fashion, but I like to view the boot progress on the console, and periodically use the console output to troubleshoot problems with the boot process. That said, it is possible to get the system services to log to the console during boot, but it requires hacking /etc/rc[0-6] to write to /dev/sysmsg instead of STDOUT. For individual startup scripts, you can add entries similar to the following to have output displayed on the console during boot:

echo “Writing to the console” > /dev/sysmsg

Console output is an extremely useful debugging tool, and I really wish you could pass an option ( boot -vx doesn’t cut it) to the kernel to tell SMF to write to the console instead of individual logfiles.

Extracting SMF site manifests

SMF is one of the new features in Solaris 10, and provides the infrastructure needed to start and stop all of the processes that make up a useful system. SMF maintains a repository to store a variety of meta data to describe a service, and this information includes the state of a given service. The state of a service can be enabled if the service is supposed to start when the system boots, or disabled if the service isn’t supposed to start when the system boots. I am a big fan of disabling every service that isn’t needed to make the server perform it’s function, and this is one area where I think SMF shines. Once I get all of the services on a Solaris 10 host configured the way I want them, I use the svccfg “extract” option to dump the service information to a site manifest:

$ svccfg extract > site.xml

After I create this manifest, I use the svccfg “apply” option to apply it to other servers:

$ svccfg apply site.xml

This is rather useful, and sure beats creating a script to do a bunch of mv SXXX to sXXXX. Nice!

Validating SMF manifests with xmllint

I recently created SMF manifests for a few services I support. When I ran svccfg to import one of the manifests, it spit out the following error indicating that it couldn’t parse the document:

$ svccfg import wls92.xml
svccfg: couldn’t parse document

Since the svccfg error message didn’t provide the number line that was causing the problem, I decided to run xmllint to see where the problem was:

$ xmllint wls92.xml

wls92.xml:13: parser error : Opening and ending tag mismatch: ervice_bundle line 3 and service_bundle </service_bundle>

It turns out that when I cut and pasted text into the new manifest, I left out a left bracket and the letter s. It’s all about getting your lint on!