1. Administrator's Guide
  2. Troubleshooting
  3. ACSLS Event Log

ACSLS Event Log

The ACSLS Event Log is the first stop for useful information if problems with your library operation occur. This log contains information about library events, status changes and errors. All sub-components within ACSLS will report events to the acsss_event.log by sending messages to a process called the Event Logger. The standard Event Log, which is automatically created when ACSLS is installed, is contained in the file $ACS_HOME/log/acsss_event.log and where $ACS_HOME is usually /export/home/ACSSS/.

Logged events include:

  • Significant Events

    Significant Events are normal events that can help you manage the library. For example, events are logged when an audit is initiated or terminated, a device changes state, or a CAP is opened or closed.

  • Library Errors

    Library Errors are events where both fatal and nonfatal hardware and software errors are logged. Examples include: LSM failures; problems with cartridges; database errors; process failures; and library communications failures.

Each message in the Event Log includes a time stamp, the name of the component reporting the message, and a description of the event. For a complete explanation of each message, consult the ACSLS Messages manual.

A window on the ACSLS console displays a running tail of the Event Log. You can generate a similar display from any shell window.

  1. As user acsss, run the following command:
    acs_tail $ACS_HOME/log/acsss_event.log
  2. To view the entire Event Log, use a text editor, such as vi, that enables you to navigate through the log, search for specific errors, or follow specific sequences of events.

Managing the Event log

ACSLS continues sending messages to the acsss_event.log.

  • When this file reaches a threshold size (500KB by default), the file is renamed to event0.log and saved in the log directory. The acsss_event.log then continues as a new file.

  • When acsss_event.log again reaches the threshold size, the event0.log is renamed to event1.log and the acsss_event.log is renamed event0.log.

  • This process continues for as many log files that are configured for retention.

By default, nine Event Log files are retained in the log directory. With each subsequent threshold, the oldest file is removed and all remaining files are sequentially renamed.

You can configure the maximum size of the acsss_event.log and the number of log files to retain using acsss_config, Option 2. See Setting CSI Tuning Variables.

Using greplog to Search Event Logs

The diagnostic tool, greplog, enables you to perform keyword searches through any and all Event Log files. Used very much like the UNIX grep utility, greplog will return the complete log message associated with a given keyword expression. This enables you see the messages' date and time stamp, message number, and the function text related to every message containing that expression.

Format

greplog [-iv] pattern file_1 file_2 ... feline

Options

  • -i instructs greplog to ignore the case of the search pattern expression.

  • -v instructs greplog to filter out all messages containing the expression and to display all of the entries in the log file. The exception are those entries which match the pattern expression.

    pattern: the pattern is the search criteria to be used.

    file_1 file_2 ... file_n

The greplog tool accepts multiple file parameters and wildcard expressions in the file list.

Examples

  • To display all occurrences within an event sequence, use the sequence number. 

    greplog 1392 acsss_event.log

  • To search the Event Log for all messages about volume CART89:

    greplog CART89 acsss_event.log

  • To search all archived copies of the Event Log for messages about tape mounts:

    greplog -i mount event*.log

Additional Logs

The acsss_event.log contains all of the messages pertaining to any aspect of the ACSLS running processes. However, there are additional files in the log directory that contain status information about external utilities, such as backup and restore and installation utilities.

  • acsss.pid - Stores the process id of the currently running acsss_daemon.

  • acsss_config.log - Contains a summary of each library configuration.

  • acsss_config_event.log - Contains event messages that were posted by the acsss_config routine.

  • bdb_event.log - Contains event messages that were posted by the database backup utility, bdb.acsss.

  • cron_event.log - Contains messages that were posted by cron utilities. To see the cron schedule, run the command crontab -l.

  • acsls_start.log - Contains startup or shutdown messages involving the acsls service.

  • di_trace.log - Contains trace information related to the database interface.

  • ejectingLogs - A directory containing summary information from ejecting.sh operations for the past ten days.

  • install.log - Contains event messages posted while running the installation script, install.sh.

  • ipc_trace.log - Contains trace information pertaining to ACSLS inter-process communications.

  • rdb_event.log - Contains event messages that were posted by the database restore utility, rdb.acsss.

  • timed_bkup.sh.log - Contains event messages related to the automatic database backup utility.

Additional trace logs may be found in the log directory depending upon the specific tracing that you have enabled on your system. The logs include the following:

  • acsss_stats.log - Volume statistics tracing is enabled by acsss_config.

  • acsss_trace.log - Client-server tracing is enabled at the request of Software Support personnel.

  • acslh.log - Host-LMU tracing is enabled at the request of Software Support personnel.

  • scsilh.log, mchangerX.log, scsipkt.log - All of these contain traces of SCSI communications to a SCSI-attached library, and are enabled at the request of Software Support.

Trace Log Management

Trace logs that are enabled at the request of Software Support can grow quite rapidly. These logs need to be monitored and managed in order to mitigate problems of a full disk.

The utility monitor.sh is provided to perform automatic log management and archiving services. The syntax, is:
monitor.sh <name of log>

When this utility is enabled to monitor a specific log, it will allow the log to grow to a size of 1MB (default) and then will compress the log using gzip, placing the compressed logfile with a time stamped name in the ACSSS/log/log_archives subdirectory. This operation will continue if tracing stays enabled.

Java Component Logs

A number of logs are maintained by the Java components in ACSLS including ACSLS GUI and Logical Library software components. These logs are found in the $ACS_HOME/log/sslm directory.

WebLogic installation procedures are logged in the weblogic.log. WebLogic and ACSLS GUI operations are logged in the AcslsDomain.log and the AdminServer.log.

An audit trail of user activity in the Web-based GUI is found in the guiAccess.log.

Transactions between Java components and legacy ACSLS components are logged in the surrogate_trace.0.log.

IPC packets between Java client components and the ACSLS server are traced in the acslm_ipc_trace.0.log.

Errors encountered by the ACSLS GUI are logged in the gui_trace.0.log.

Low-level communication between the SMCE and the SCSI (fibre) client are logged in the smce_trace.0.log.

These logs are found in the $ACS_HOME/log/sslm directory.