OpenSolaris has by far, one of the best service management interfaces that I have used. Below I am going to go over a simple way to turn in shell script into a service managed by the OS.
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>
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.
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 ).
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.
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.
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.