Understanding the cluster.log file

The /var/hacmp/adm/cluster.log file is a standard text file. When checking this file, first find the most recent error message associated with your problem. Then read back through the log file to the first message relating to that problem. Many error messages cascade from an initial error that usually indicates the problem source.

Format of messages in the cluster.log file

The entries in the /var/hacmp/adm/cluster.log file use the following format:

Figure 1. Format for entries
Format for entries. Includes timestamp, node, subsystem, PDF, and message.

Each entry has the following information:

Table 1. cluster.log file
Entry Description
Date and Time stamp The day and time on which the event occurred.
Node The node on which the event occurred.
Subsystem The PowerHA® SystemMirror® subsystem that generated the event. The subsystems are identified by the following abbreviations:
  • clstrmgrES - the Cluster Manager daemon
  • clinfoES - the Cluster Information Program daemon
PID The process ID of the daemon generating the message (not included for messages output by scripts).
Message The message text.

The entry in the previous example indicates that the Cluster Information program (clinfoES) stopped running on the node named nodeA at 5:25 P.M. on March 3.

Because the /var/hacmp/adm/cluster.log file is a standard ASCII text file, you can view it using standard AIX® file commands, such as the more or tail commands. However, you can also use the SMIT interface. The following sections describe each of the options.

Viewing the cluster.log file using SMIT

To view the /var/hacmp/adm/cluster.log file using SMIT:

  1. Enter smit hacmp.
  2. In SMIT, select Problem Determination Tools > PowerHA SystemMirror Log Viewing and Management > View Detailed PowerHA SystemMirror Log Files and press Enter.
  3. Select Scan the PowerHA SystemMirror for AIX System Log and press Enter. This option references the /var/hacmp/adm/cluster.log file.
    Note: You can select to either scan the contents of the cluster.log file as it exists, or you can watch an active log file as new events are appended to it in real time. Typically, you scan the file to try to find a problem that has already occurred; you watch the file as you test a solution to a problem to determine the results.