Enterprise Software

Get IT Done: Start and stop applications automatically using Solaris scripts

Discusses the best way to start and stop Solaris applications for a problem-free startup or shutdown

If you’re a Windows network administrator who is facing Solaris for the first time, you’ll quickly discover that UNIX in general, and Solaris in particular, is a little more complicated and a little less forgiving than Windows. There is no Startup folder to drop applications into in order to have them start when the machine starts. There is also no Services Control Panel to use to stop services and applications. Applications running under UNIX usually don’t take well to being suddenly stopped—most prefer a graceful shutdown procedure. Let's discuss the best way to start and stop Solaris applications.

Before you begin…
This article assumes a basic knowledge of UNIX and a basic knowledge of vi, the text editor included with every UNIX platform. You’ll need vi to create the scripts I'll discuss in this article. I wrote this article based on Solaris 7, but the same structures hold true for Solaris 8 and 9. In addition, many other UNIX platforms, such as Compaq UNIX, use very similar structures.

Solaris run levels
To start and stop applications, you should first understand a little about Solaris run levels and the files and directories involved in setting up the start and stop processes. A run level is a system state that runs a particular set of processes. Solaris provides the following eight run levels:
  • ·        S or s—Single-user modes; does not require the system to be entirely configured; can be used in recovering from a crash
  • ·        0—Causes the system to read firmware
  • ·        1—System admin mode only; no users allowed on the system, but all local file systems are mounted
  • ·        2—Multiuser mode, the most common mode; allows users on the system
  • ·        3—Extended multiuser mode; same as mode 2 but makes local resources available to the network
  • ·        4—Multiuser mode; can be customized by the administrator
  • ·        5—Shutdown mode; remove the power if possible
  • ·        6—Reboot mode; reboots the machine into the default run level

I'll concentrate on mode 2, since it's the most common mode.

Files and directories control the starting and stopping of a set of processes for a run level. Most of the directories include a README file, which gives very basic information on the files in that directory. These directories include:
  • ·        /etc—This directory contains most system configuration files and reference files. For example, /etc/hosts contains the local list of known system names and IP addresses.
  • ·        /etc/init.d—This directory contains the start and stop scripts used when the run state is changed. These scripts are then symbolically linked to the appropriate run level directory.
  • ·        /etc/rc[S0-6].d—These are the run level directories that contain links to the /etc/init.d scripts used by the particular run state. This article will concentrate on using /etc/rc2.d, which is the directory for run level 2.

Solaris files don’t have the .cmd, .bat, or .exe extensions that you’re used to seeing. Here are the files you’ll be using to stop and start applications:
  • ·        /etc/inittab—This file contains an entry that specifies the default run level. If you open the file with vi, look for the entry that contains "initdefault" in the third field. This entry specifies the run level.
  • ·        /etc/rc[S0-6]—This file contains the commands run by /sbin/init when changing run levels. It controls the use of the files found in the run level directory. You’ll replace [S0-6] with the run level you’ll be working on. So, when dealing with run level 2, you’ll be dealing with /etc/rc2.
  • ·        /etc/rc[S0-6].d/[SK][###]name—Again, here you’ll replace [S0-6] with the run level you’ll be working on. SK represents the action you want to take: S to start, K to kill or stop. You’ll replace ### with the sequence number, which I’ll discuss later. Finally, you’ll replace name with the name of the script. You’ll symbolically link this name in /etc/init.d. An example of valid filenames is S98netscape to start and K98netscape to kill the Netscape server.

A practical example
So how do you take all of this information and put it together to start up something? Here's an example to follow. The steps I describe will show you how to have a Netscape Suitespot Web server start when the Solaris machine reaches multiuser run level, and stop cleanly when it leaves the multiuser run level.

I’m going to assume that the Netscape Suitespot server is fully configured and able to start and stop automatically. I’m not going to show you how to actually configure Netscape to do this—that's beyond the scope of this article.

First, look in /etc/inittab and find the default run level in order to know where to place the start and stop scripts. Open a command console in Solaris and switch to the /etc directory. Then, start vi and load inittab by typing vi inittab and pressing [Enter]. You’ll then see the contents of inittab appear. You can see a sample inittab in Listing A.

Note that the fields are separated by colons. The entry of interest is the one with the initdefault in the third field, bolded in the example. The run level associated with the entry is in the second field. You’ll notice that even though I said that the most common run level is 2, in this example, the default is 3.

Why does the run level matter?
This README file in /etc/rc3.d is a guide for developers who need to provide scripts to start up their product as the init state changes to multiuser mode, with network resources exported (i.e., run level 3). Run level 3 is the default run level. Note that the transition to run level 3 from run levels S, 0, or 1 includes a transition through run level 2. So links to scripts in /etc/rc2.d should not be duplicated in /etc/rc3.d. Only those services that are running in run level 3, but not in run level 2, should be started by scripts in /etc/rc3.d.

In short, when the system is booted, it will transition through run level 1 automatically and will go through run level 2 before reaching the default run level 3. So, start and stop scripts, unless they are dependent on the exporting of other network resources, should be placed in /etc/rc2.d.

As mentioned, the script will be placed in /etc/init.d and be symbolically linked to /etc/rc2.d. To find out the proper sequence number to use, take a look at the README from /etc/rc2.d. It will indicate the following sequence points for the transition to single-user mode:
  • ·        After the S20 scripts have executed, local file systems are mounted and temporary directories have been cleaned as appropriate.
  • ·        After the S80 scripts have executed, the machine is a fully configured NFS client. NFS file systems have been mounted. The name service (if any) is running, and syslogd and cron are running.

If your start process—in this case, Netscape—needs a locally mounted file system, it must be named with a number greater than 20; if it needs any NFS resources, it must be named with a number greater than 80. In the case of Netscape Suitespot, it will need some local file systems to start and may depend on NFS, because the binaries for the server could be mounted from another system. So you should name the script with a number greater than 80. Because Netscape isn't dependent on other system processes to run, you can choose any number greater than 80. For this example, I'll use 98.

You can create a single script in /etc/init.d that will both start and stop the Netscape Suitespot server. You can do this easily with a case statement in the script, because Solaris calls the scripts it finds with either start or stop as the first parameter. Scripts named with an S are called with start, and scripts named with a K are called with stop.

Listing B  shows a script that will start and stop the Netscape server. The mechanics and syntax of the script will not be explained here. Suffice it to say that the script examines the first parameter passed to the script and acts appropriately.

You can create the script with vi or any other text editor. Save the script under the filename /etc/init.d/netscape. If the script is called with the start parameter, it will change to the directory where the server is installed and issue a start command. Likewise, if the script is called with the stop parameter, it will change to the directory where the server is installed and issue a stop command.

After you save the script, you need to link it to the /etc/rc2.d directory as both an S and K script. To do so, issue the following commands to create the symbolic links:
$ ln –s /etc/init.d/netscape /etc/rc2.d/S98netscape
$ ln –s /etc/init.d/netscape /etc/rc2.d/K98netscape

After you’ve created the links, you can test the script. You’ll need to run the commands as root. To test a startup, type # /etc/rc2.d/S98netscape start and press [Enter]. If the start script works properly and Netscape fires up, you’ll see output similar to the following:
Netscape-Enterprise/3.6 SP2 B99.113.0837
startup: listening to http://server1.domain.com, port 80 as nobody

To test the stop script, type # /etc/rc2.d/K98netscape stop and press [Enter]. If the stop script works properly and the Netscape server stops, you’ll see:

A few things to keep in mind about the scripts
That’s all there is to it. You now have a working startup and shutdown script for a Netscape Suitespot server. You can use the logic here to start or stop any program such as database servers and application servers. Keep the following things in mind about scripts as you create them:
  • ·        The script may not require any interaction from the user, since the init process is the user and it issues the command only with the appropriate start or stop parameter.
  • ·        Any output generated by the script will be disregarded by the init process, but will be recorded in the system logs as appropriate. The output generated in the example script is for the times when the script is run interactively.
  • ·        The environment must be set within the script, because there is a minimum environment used by the init process. For example, if there is a need for an environment variable, such as SERVERNAME, to be set, it must be explicitly set in the proper syntax for the shell used. The script /etc/init.d/dhcp shows the setting of a variable.
  • ·        By default, the shell used to run the scripts is the Bourne shell. It can be forced to another shell, as shown by the first line in my example script.
  • ·        All scripting conventions including functions are valid in the start and stop scripts.
  • ·        Scripts should be kept as simple as possible and should not depend on other scripts, which might be altered by other users. If a change is made outside the script, it may cause a failure in system startup.

Editor's Picks