Chapter 26. System Resource Controller

This article provides information about the System Resource Controller (SRC), which facilitates the management and control of complex subsystems.

The SRC is a subsystem controller. Subsystem programmers who own one or more daemon processes can use SRC services to define a consistent system management interface for their applications. The SRC provides a single set of commands to start, stop, trace, refresh, and query the status of a subsystem.

In addition, the SRC provides an error notification facility. You can use this facility to incorporate subsystem-specific recovery methods. The type of recovery information included is limited only by the requirement that the notify method is a string in a file and is executable.

Refer to the following information to learn more about SRC programming requirements:

• SRC Objects
• SRC Communication Types
• Programming Subsystem Communication with the SRC
• Defining Your Subsystem to the SRC
• List of Additional SRC Subroutines

Subsystem Interaction with the SRC

The SRC defines a subsystem as a program or set of related programs designed as a unit to perform related functions. See "System Resource Controller Overview" in AIX Version 4.3 System Management Guide: Operating System and Devices for a more detailed description of the characteristics of a subsystem.

A subserver, commonly known to UNIX programmers as a daemon, is a process that belongs to and is controlled by a subsystem.

The SRC operates on objects in the SRC object class. Subsystems are defined to the SRC as subsystem objects; subservers, as subserver-type objects. The structures associated with each type of object are predefined in the usr/include/sys/srcobj.h file.

The SRC can issue SRC commands against objects at the subsystem, subserver, and subsystem-group levels. A subsystem group is a group of any user-specified subsystems. Grouping subsystems allows multiple subsystems to be controlled by invoking a single command. Groups of subsystems may also share a common notification method.

The SRC communicates with subsystems by sending signals and exchanging request and reply packets. In addition to signals, the SRC recognizes the sockets and IPC message-queue communication types. A number of subroutines are available as an SRC API to assist in programming communication between subsystems and the SRC. The SRC API also supports programming communication between client programs and the SRC.

The SRC and the init Command

The SRC is operationally independent of the init command. However, the SRC is intended to extend the process-spawning functionality provided by this command. In addition to providing a single point of control to start, stop, trace, refresh, and query the status of subsystems, the SRC can control the operations of individual subsystems, support remote system control, and log subsystem failures.

Operationally, the only time the init command and the SRC interact occurs when the srcmstr (SRC master) daemon is embedded within the inittab file. (By default, the srcmstr daemon is in the inittab file.) In this case, the init command starts the srcmstr daemon at system startup, as with all other processes. You must have root user authority or be in the system group to invoke the srcmstr daemon.

Compiling Programs to Interact With the srcmstr Daemon

To enable programs to interact with the srcmstr daemon, the /usr/include/spc.h file should be included and the program should be compiled with the libsrc.a library. This support is not needed if the subsystem uses signals to communicate with the SRC.

SRC Operations

To make use of SRC functionality, a subsystem must interact with the srcmstr daemon in two ways:

• A subsystem object must be created for the subsystem in the SRC subsystem object class.
• If a subsystem uses signals, it does not need to use SRC subroutines. However, if it uses message queues or sockets, it must respond to stop requests using the SRC subroutines.

All SRC subsystems must support the stopsrc command. The SRC uses this command to stop subsystems and their subservers with the SIGNORM (stop normal), SIGFORCE (stop force), or SIGCANCEL (cancel systems) signals.

Subsystem support is optional for the startsrc, lssrc -l, traceson, tracesoff, and refresh commands, long status and subserver status reporting, and the SRC notification mechanism. See "Programming Subsystem Communication with the SRC" for details.

SRC Capabilities

The SRC provides the following support for the subsystem programmer:

• A common command interface to support starting, stopping, and sending requests to a subsystem
• A central point of control for subsystems and groups of subsystems
• A common format for requests to the subsystem
• A definition of subservers so that each subserver can be managed as it is uniquely defined to the subsystem
• The ability to define subsystem-specific error notification methods
• The ability to define subsystem-specific responses to requests for status, trace support, and configuration refresh
• A single point of control for servicing subsystem requests in a network computing environment

Related Information

System Resource Controller Overview

Understanding SRC Objects

Understanding SRC Communication Types

Programming Subsystem Communication with the SRC

Defining Your Subsystem to the SRC

List of Additional SRC Subroutines

Object Data Manager Overview for Programmers.