Action 2: verify the status of the Group Services subsystem
On AIX® nodes, the AIX error log entry GS_DOM_MERGE_ER indicates that the Group Services daemon has restarted. On Linux® nodes, the same entry, GS_DOM_MERGE_ER, in the file /var/log/messages* also indicates that the Group Services daemon has restarted. On Windows nodes, the same entry, GS_DOM_MERGE_ER, in the file /var/adm/log/messages* indicates that the Group Services daemon has restarted. On Solaris nodes, the GS_DOM_MERGE_ER entry in the file /var/adm/messages* also indicates that the Group Services daemon has restarted.
The most common condition suggesting this action is the Group Services daemon receipt of a NODE_UP event from Topology Services after the Group Services daemon formed more than one domain.
If the Group Services daemon has been restarted and a domain has been formed, no action is needed. However, if the Group Services daemon is not restarted, perform Operational test 1: verify that Group Services is working properly to verify the status of the Group Services subsystem.
- Find a node with the GS_DOM_MERGE_ER in the AIX error log (on AIX nodes), or in the file /var/log/messages* (on Linux nodes), in the file /var/adm/log/messages* (on Windows nodes) or in the file /var/adm/messages* (on Solaris nodes).
- Find the GS_START_ST entry before the GS_DOM_MERGE_ER in the log.
- If there is a GS_START_ST entry, issue the lssrc command:Where subsystem_name is cthags.
lssrc -l -s subsystem_name - The lssrc output contains the node number that established the Group Services domain.
- Otherwise, proceed to Operational test 3: determine why the Group Services domain is not established.
After the merge, the Group Services daemon must be restarted. See TS_NODEUP_ST (the label of a Topology Services error log template) located in Error logs and templates. Check it with Operational test 2: determine why the Group Services subsystem is not active.