IBM Books

Administration Guide


Controlling the sequence of startup and shutdown operations

Your SP might be a complex group of nodes, each dependent on other nodes for some resources. Startup and shutdown operations must occur in the proper sequence so that these dependencies are honored. As a simple example, a server node might have to be running before its client nodes are started up. A server node should not shut down before its clients have been shut down. The seqfile command defines sequencing relationships that result from using boot-install servers. You can define additional dependencies.

To provide best performance, cstartup and cshutdown can operate on multiple nodes concurrently.

Note:
Given appropriate time-out values, the cstartup and cshutdown commands, properly handle any SP Expansion I/O Units that are connected to POWER3 SMP high nodes.

Similar considerations apply to the shutdown of special subsystems (see Creating a special subsystem) that run on multiple nodes in the SP system. An example of a subsystem is a file system that spans several nodes within a system partition. Subsystems might need to do special processing to prepare for the shutdown of one or more nodes, or a set of subsystems might need to shut down in a specific order.

You must define the sequencing relationships between your nodes. For example, boot-install servers must start up before their clients. Other programs on your SP system might create additional sequencing relationships.

The node sequence files, /etc/cshutSeq and /etc/cstartSeq, have lines that describe these dependencies. In these files, you define the groups of nodes and the sequence in which the groups are started up or shut down. If you don't have a node sequence file, some sequencing is performed automatically. The seqfile command helps you create these files by generating definitions for groups of nodes and their sequencing order for dependencies relating to boot-install servers and their clients.

You can also create a subsystem sequence file, /etc/subsysSeq, which lists the subsystems, defines groups of subsystems, and defines relationships between subsystems. If you don't have a subsystem sequence file, no subsystems are notified of an impending node shutdown.

The sequence files, which reside on the control workstation, are:

/etc/cstartSeq
Startup. The list defining groups of nodes and the order of startup processing.

/etc/cshutSeq
Shutdown. The list defining groups of nodes and the order of shutdown processing.

/etc/subsysSeq
Special subsystems. The list defining special subsystems, groups of special subsystems, and the order of shutdown processing.

The node sequence files are separate to allow for different startup and shutdown dependencies. However, if your startup and shutdown dependencies are mirror images, you can maintain a single file; create a symbolic link to provide both file names.

Defining startup and shutdown sequence files describes the format of the sequence files and their interactions with command line flags.

Default node sequencing

The SP system can do some sequencing automatically during system startup or shutdown. The seqfile command shows you the default sequencing relationships.

If you don't create the /etc/cstartSeq file, the cstartup command uses a default sequence based on the SDR. Any nodes defined in the SDR as boot-install servers are started up concurrently. After the servers are running, nodes defined as boot-install clients are started up. If you create an empty /etc/cstartSeq file, then all nodes are started up concurrently.

If you don't create an /etc/cshutSeq file, cshutdown uses a default sequence based on the SDR. If you create an empty /etc/cshutSeq file, then all nodes are shut down concurrently. If you don't have a /etc/subsysSeq file or the file is empty, no special subsystem shutdown occurs.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]