Wednesday, August 29, 2012

Solaris: starting/controlling services

SMF: starting/controlling services In most Unix systems, startup scripts in /etc/rc3.d, etc, are used to start and stop services. Solaris 10 uses a different approach. There are two advantages to the Solaris 10 method: The system can come up faster, because startup of various systems can be done in parallel.
The system knows more about what is going on. It can monitor processes and restart them.
Services are managed by svcadm. The most common commands are svcadm enable SERVICE
svcadm disable SERVICE Note that enable and disable are persistent. That is, if you enable a service it will be brought back up after a reboot. Similarly with disabling. If you want to stop a service but have it come back up after the next reboot, use "svcadm -t disable SERVICE". That stops it temporarily.
To look at services, two common commands are svcs {lists summary of all}
svcs -l SERVICE {details on one service}
Solaris 10 still pays attention to /etc/rcN.d, but services defined there are "legacy", and can't be fully monitored and controlled. To define a service, you create an XML file that specifies dependencies, and methods to start and stop it. Then you do "svccfg import FOO.xml". Normally the XML file is written to create an instance but not enable it. So if the import works, you would need to do "svcadm enable SERVICE" to start it. A good way to start writing the XML file is to look at existing ones. They are in subdirectories of /var/svc/manifest. Sun suggests system/utmp.xml as a simple example. Since many of your services may be network services, take a look at what is in network. In network, there are two types of services, some that are standard daemons (e.g. http_apache2) and some there are run by inet (e.g. telnet). If you add services, you probably want to put your .xml files in /var/svc/manifest and your scripts in /lib/svc/method. That way anyone who needs to work with the system can find them, just as they now know to look in /etc/init.d for all startup scripts. However I suggest making those symbolic links to files that are actually in /usr/local/svc/manifest and /usr/local/svc/method. That way you won't lose your information in a system reinstallation. I suggest two pages in Sun's BIGADMIN site: Predictive Self-Healing. This is the best brief introduction to the SMF system.
Configuring JBoss to use with SFM Step by step instructions to configure a typical daemon. Note there is one possible error in the XML. One dependency is given a name of "ssh_multi-user-server". I had problems until I changed the name. I suggest SERVICE_multi-user-server, where SERVICE is your service name.
Most of the XML files refer to scripts to do start, stop and restart. The Sun scripts all reside in /lib/svc/method. It's worth looking at some of the examples. There are two standard approaches: a script that just starts the service. You then use :kill in the XML file to stop it. This causes all processes started by the start script to be killed. Or you have a script that looks a lot like a traditional init.d script, which is called as "SCRIPT start" and "SCRIPT stop". Use that if you need to do something beyond just killing the process. For a quick conversion you can use the example above, and call the init.d script with start and stop. However you may want to change the script slightly: Be careful about return values. You should return 0 if the action is taken. (With stop you should return 0 even if the process was already stopped.) Otherwise you'll need to return a value defined by SMF.
When starting and stopping, don't return until the process is running and ready to respond to user requests, or until it's really dead. If you need to wait, make sure you use a timeout.
The second item is critical if other processes depend upon this one, since they'll go on to the dependencies as soon as the start process returns. If there are no dependencies, you can get away with a simple init.d script, as long as it returns 0.
Note that if all processes started by a service die, the system will try to restart the service by doing a stop and then a start. You can also define a "refresh" action, which prods a service if a configuration file changes.

No comments:

Post a Comment