Managing Serviceguard A.11.20, March 2013

The reason may be that you have not updated the authorization file. Verify that the node is included
in the file, and try using /usr/lbin/qs -update to re-read the Quorum Server authorization
file.
Timeout Problems
The following kinds of message in a Serviceguard node’s syslog file may indicate timeout
problems:
Unable to set client version at quorum server 192.6.7.2: reply timed
out
Probe of quorum server 192.6.7.2 timed out
These messages could be an indication of an intermittent network problem; or the default Quorum
Server timeout may not be sufficient. You can set the QS_TIMEOUT_EXTENSION to increase the
timeout, or you can increase the MEMBER_TIMEOUT value. See “Cluster Configuration Parameters
” (page 114) for more information about these parameters.
A message such as the following in a Serviceguard node’s syslog file indicates that the node
did not receive a reply to its lock request on time. This could be because of delay in communication
between the node and the Quorum Server or between the Quorum Server and other nodes in the
cluster:
Attempt to get lock /sg/cluser1 unsuccessful. Reason:
request_timedout
Messages
Serviceguard sometimes sends a request to the Quorum Server to set the lock state. (This is different
from a request to obtain the lock in tie-breaking.) If the Quorum Server’s connection to one of the
cluster nodes has not completed, the request to set may fail with a two-line message like the following
in the quorum server’s log file:
Oct 008 16:10:05:0: There is no connection to the applicant
2 for lock /sg/lockTest1
Oct 08 16:10:05:0:Request for lock /sg/lockTest1 from
applicant 1 failed: not connected to all applicants.
This condition can be ignored. The request will be retried a few seconds later and will succeed.
The following message is logged:
Oct 008 16:10:06:0: Request for lock /sg/lockTest1
succeeded. New lock owners: 1,2.
Solving Problems 345