Step 1: Create the Service Manifest

<?xml version='1.0'?>;
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='mynewservices'>
        <service name='application/service1' type='service' version="1">
                <method_context>
                        <method_credential user='root' />
                        <method_environment>;
                                <envvar name="MY_VAR" value="--flag1 --flag2" />
                        </method_environment>
                </method_context>
 
                <exec_method name='start' type='method' exec='/opt/myscript.sh start' timeout_seconds='0' />
 
                <exec_method name='stop' type='method' exec='/opt/myscript.sh stop' timeout_seconds='120' />
        </service>
</service_bundle>

Service Bundle

A service bundle is just a collection of services which can be very useful if you have a suite of applications that you wish to manage within on manifest.xml file.

Service

The attributes you define on your service can be anything and are only useful for when you invoke administrative commands on them ( start, stop, etc ).

Method Context

The method context allows you to define the environment in which the executed methods will be called within. The example above shows the ability to define what user will be used to execute the method and the environment variables available to the script. This can be very handy when you want to leave an installation directory’s bin alone, and configure everything through the service. Keep in mind that what you see is a global method context and will apply to all executed methods. You may also customize the context per method by moving the tags out of service and into the exec_method tags.

Executable Method

Its purpose is self explanatory. Note that in one entry, the timeout is 0 and the other is 120 seconds. A timeout with a value of 0 will wait indefinitely for the script to start-up, however the service manager will always assume that it is online when in fact it could be hanging.

Also, there are three common commands used when invoking the service manager; enable, disable, and restart.

• When enabled, the start method will be executed.
• When disabled, the stop method will be executed.
• When restarted/refreshed, both the stop and the start method will be executed unless there is a method named restart/refresh.

Step 2: Import the Manifest

Once you have your manifest xml file completed and ready to import, all you need to do is run the following commands:

svccfg validate manifest.xml

That will run the configuration through validation and make sure you didn’t make any typo’s.

svcfg import manifest.xml

Step 3: Enable the Service

Now that your manifest has been imported, it is available to be enabled within the service admin.

svcadm enable service1

Step 4: Testing the Service

After the service has started the run, you need to make sure it is executing properly and can handle a machine restart and/or service restart.

svcs -x

That command will tell you which services are currently broken and the log files to view the errors. Make sure that your service is not in that list. You may also do the following:

svcs service1
svcs -x service1

to determine the state of that particular service. If it isn’t working, I suggest taking a look at the log files and fix it

Step 5: Updating the Service

Say that while testing, you noticed that you passed the wrong parameter to your shell script or maybe in the future you need to add additional environment variables to your service, its the same process. Even if you no longer have the manifest xml file, SMF will give you a copy when you ask for it so that you can modify it and re-import.

svccfg export myservices > manifest.xml

After you have made your changes, validate and import the xml file and restart your service.

perl -MCPAN -e "install HTML::Mason"

Generally the first thing I notice is that all (or a large number) of the tests are failing. For example here is the output of one of the tests:

t/20-plugins.......................Can't locate HTML/Entities.pm in @INC (@INC
 contains: /root/.cpan/build/HTML-Mason-1.42/blib/lib /root/.cpan/build/H
TML-Mason-1.42/blib/arch t/lib inc /usr/perl5/5.8.4/lib/i86pc-solaris-64int
 /usr/perl5/5.8.4/lib/i86pc-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_
perl/5.8.4/i86pc-solaris-64int /usr/perl5/site_perl/5.8.4/i86pc-solaris-64int
 /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl/5.8.4/i86pc-solaris-64int /u
sr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/i8
6pc-solaris-64int /usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int /usr/per
l5/vendor_perl/5.8.4 /usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int /usr
/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl . /usr/perl5/5.8.4/lib/i86pc
-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/i86pc-solaris-6
4int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.
8.4/i86pc-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl 
.) at /root/.cpan/build/HTML-Mason-1.42/blib/lib/HTML/Mason/Escapes.pm
 line 14.

Hmm, because we’re not installing HTML::Entities this means that it should have been brought in when CPAN.pm was building the dependencies. I trust CPAN.pm got this right, if for no other reason than that I remember it prompting to install that module. After digging around in the sea of output eventually I find that installing Digest::SHA1 failed because of this error:

cc -c   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO -xO3 -xspace -xildoff   -DVERSION=\"2.12\" -DXS_VERSION=\"2.12\" -KPIC "-I/usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE"   SHA1.c
cc: unrecognized option `-KPIC'
cc: language ildoff not recognized
cc: SHA1.c: linker input file unused because linking not done

Our C compiler isn’t happy with how it’s being called. Now we need to find out which compiler we’re using:

 bash-3.2$ which cc
/usr/gnu/bin/cc

While the GCC compiler is a fine fine compiler, the way CPAN.pm tries to build things on OpenSolaris involves params that only SunStudio understands. At this point there are two options. We can either patch the generated Makefile so that it doesn’t include stuff GCC can’t understand or we can switch the compiler to SunStudio. I prefer the latter because it is easiest:

pkg install sunstudio  # Install it if not already done
export PATH="/opt/SUNWspro/bin:$PATH" # Put it first on the path

Now that we’re using the correct compiler the build goes slightly less awful. We get a new error.

/usr/bin/perl "-Iblib/arch" "-Iblib/lib" Build.PL Build
Too early to specify a build action 'Build'.  Do 'Build Build' instead.

This is caused by the ExtUtils::MakeMaker module not being installed. I don’t know how my system got into such a state, but it is easy enough to fix:

perl -MCPAN -e "install 'ExtUtils::MakeMaker' "

Let’s try one more time:

perl -MCPAN -e "install HTML::Mason"
...Huge Snip...
 /usr/gnu/bin/make install  -- OK

Success!