2 Starting and Monitoring ACSLS

Once ACSLS has been installed and configured with the attached library, the application can be enabled with the command, acsss enable. The acsss macro manipulates the multiple services that are associated with ACSLS, bringing them up and shutting them down in the proper order, and providing a high-level view of the overall system status.

Depending on the installation, an ACSLS application is an aggregate consisting of up to seven services that are installed on the Solaris or Linux system:

  • acsdb - maintains the ACSLS library database.

  • acsls - library control software that executes library operations.

  • weblogic - web server for the ACSLS GUI.

  • surrogate - communication link between java services and acsls.

  • rmi-registry - lookup service for named java objects and methods.

  • smce - SCSI Media Changer Emulation of logical libraries.

  • stmf - target mode framework for logical libraries.

The first two services are common to all installations. The weblogic, surrogate, and rmi-registry services are present where the ACSLS GUI has been installed. The smce and stmf service is seen on Solaris systems where logical library support has been configured. All of theses services are manipulated by the ACSLS user with the single macro, acsss.

Starting ACSLS

As root, start ACSLS by running:

acsss enable

This command is the default method for bringing up ACSLS. It checks for dependencies and activates, in the proper order, the various ACSLS services and the ACSLS GUI. The services are configured to start automatically after system reboot.

Monitoring ACSLS

For a quick status report of the various ACSLS services, run the command:

acsss status

Stopping ACSLS

Stopping ACSLS is not a complete shutdown and enables the database and any GUI login sessions to remain active for maintenance operations after the acsls and smce services have been disabled. Use this procedure to shut down ACSLS and the database.

To stop the ACSLS, use the command:

acsss disable

SMF Timeout on Solaris

The Solaris SMF utility allots a set amount of time for each service to become fully enabled. For the acsls service, this time limit is calculated on the basis of the library configuration: the number of LSMs, the number of drives, and the number of CAPs. A large library configuration takes longer for ACSLS to recover than a smaller configuration, so a longer SMF timeout period is allotted to a larger configuration.

On rare occasions, a faulty LSM may take more time to come up than the SMF time limit allows. When the time-out period has expired, SMF will restart the operation. This action has the potential for the start sequence to go into an endless loop, preventing ACSLS from ever recovering during difficult startup conditions.

A special file, acsls_startup_policy, is intended for use in such situations. This file, located in the $ACS_HOME/data/external directory, when configured adds extra time for startup recovery, or to exempt any specific ACS from being recovered during the SMF startup sequence. Detailed configuration instructions are contained in the header remarks of acsls_startup_policy. By adjusting the start-up parameters in this file, you can avoid ACSLS startup problems introduced by an abnormal library startup condition.

For more information, refer to "Diagnosing ACSLS Startup Problems".

ACSLS Startup Policy

This file alters the normal startup parameters that apply when starting ACSLS. Changing the default startup values is not recommended without careful analysis and consultation with Oracle ACSLS Software Support.

Additional Startup Time

This parameter applies to the SMF startup timeout for the acsls service on Solaris. The acsls startup timeout is calculated automatically by the current library configuration. A longer timeout is given to libraries that have more LSMs, more drives and more CAPs. This timeout will adjust automatically as the library configuration changes. you can view the calculated value by asserting the command:

acsss timeout

If the automatic calculated timeout is not sufficient, the SMF facility may intervene to restart the acsls service before sufficient time had elapsed to allow the previous startup sequence to finish.

Granting more time to the startup sequence can prevent such SMF intervention, but not without compromises. Adding too much time can mask troublesome aspects of the configuration that may require attention. Extending the normal timeout period delays SMFs' ability to alert an operator of any serious or irrecoverable startup problems.

To grant additional minutes for the acsls start sequence to complete, place integer value after the '=' in the following line:

additional_startup_time=0 # Minutes

Desired (offline) Startup State for an ACS

When ACSLS comes up, it will bring all of the library resources to the last established desired state. If the desired state is online, the process of bringing the ACS online involves a recovery period in which the physical library resources of the given ACS are checked and verified against the database image of the configuration. This process transpires within a span from less than a minute to several minutes, depending on the size of the library configuration and on the existence of any unusual circumstances.

You can bypass this recovery time for any ACS by placing the desired state of that ACS and its associated ports offline. While such action speeds the online status of the acsls SMF service, subsequent manual action is necessary to vary the actual ACS and its port(s) online.

To set the desired startup state of an ACS and its ports to offline, remove the comment character (#) from the beginning of the appropriate line in the acsls_startup_policy file in the $ACS_HOME/data/external/ directory.

For example, change:

# ACS0_desired_startup_state_is_offline

to:

ACS0_desired_startup_state_is_offline