Operational test 2: determine why the Group Services subsystem is not active

Use this test to determine why the Group Services subsystem has become inactive.

Table 1 describes how to determine why a Group Services subsystem may not be active. These procedures vary by node type, as follows:

Table 1. Determine why the Group Services subsystem is not active on Linux, AIX, Windows, and Solaris nodes
Node	Instructions
On Linux® nodes:	Examine at the /var/log/messages* files which have system logs that may indicate what the error is. For details about error log entries, look at the entries related to Group Services, which have labels beginning with GS_, such as GS_START_ST, GS_STARTERR_ER, and others. The error log entry, together with its description, is located in Error logs and templates. If there is no GS_ error log entry explaining why the subsystem went down or could not start, the daemon may have exited abnormally. See Core dump if RSCT has produced a core file in /var/ct/cluster_name/run/cthags. If there is a core file, see Information to collect before contacting the IBM Support Center and contact the IBM Support Center. For errors where the daemon did start up, but then exited during initialization, locate detailed information about the problem in the Group Service start script log. For additional information, see Group Services startup script log.
On AIX® nodes:	Enter the command: `errpt -N cthags` and look for an entry for the cthags. It appears under the `RESOURCE_NAME` heading. If an entry is found, enter the command: `errpt -a -N cthags` to get details about error log entries. The entries related to Group Services are those with `LABEL` beginning with GS_. The error log entry, together with its description in Error logs and templates, explains why the subsystem is inactive. If there is no GS_ error log entry explaining why the subsystem went down or could not start, it is possible that the daemon may have exited abnormally. Look for an error entry with `LABEL` of CORE_DUMP and `PROGRAM NAME` of hagsd, by issuing the command: `errpt -J CORE_DUMP` If this entry is found, see Information to collect before contacting the IBM Support Center and contact the IBM Support Center. Another possibility when there is no GS_ error log entry is that the Group Services daemon could not be loaded. In this case, a message similar to the following may be present in the Group Services startup log: `0509-036 Cannot load program hagsd because of the following errors: 0509-026 System error: Cannot run a file that does not have a valid format.` The message may refer to the Group Services daemon, or to some other program invoked by the startup script cthags. If this error is found, see Information to collect before contacting the IBM Support Center and contact the IBM Support Center. For errors where the daemon did start up but then exited during initialization, locate detailed information about the problem in the Group Service start script log. For additional information, see Group Services startup script log
On Windows nodes:	Examine at the /var/adm/log/messages* files which have system logs that may indicate what the error is. For details about error log entries, look at the entries related to Group Services, which have labels beginning with GS_, such as GS_START_ST, GS_STARTERR_ER, and others. The error log entry, together with its description, is located in Error logs and templates. If there is no GS_ error log entry explaining why the subsystem went down or could not start, the daemon may have exited abnormally. See Core dump if RSCT has produced a core file in /var/ct/cluster_name/run/cthags. If there is a core file, see Information to collect before contacting the IBM Support Center and contact the IBM Support Center. For errors where the daemon did start up, but then exited during initialization, locate detailed information about the problem in the Group Service start script log. For additional information, see Group Services startup script log.
On Solaris nodes:	Examine at the /var/adm/messages* files which have system logs that may indicate what the error is. For details about error log entries, look at the entries related to Group Services, which have labels beginning with GS_, such as GS_START_ST, GS_STARTERR_ER, and others. The error log entry, together with its description, is located in Error logs and templates. If there is no GS_ error log entry explaining why the subsystem went down or could not start, the daemon may have exited abnormally. See Core dump if RSCT has produced a core file in /var/ct/cluster_name/run/cthags. If there is a core file, see Information to collect before contacting the IBM Support Center and contact the IBM Support Center. For errors where the daemon did start up, but then exited during initialization, locate detailed information about the problem in the Group Service start script log. For additional information, see Group Services startup script log.