Known Problems and Workarounds

The following describes known problems with the Continentalclusters and workarounds for them. This is subject to change without notice. For the most current information contact your HP support representative.

More recent information on known problems and workarounds may be available on the Hewlett Packard IT Resource Center:

http://itrc.hp.com (Americas and Asia Pacific)

http://europe.itrc.hp.com (Europe)

misleading recovery message

What is the problem?
In Serviceguard 11.15 environment, the message, “The id of the user requesting the connection is not available in the authentication session” may occur when running cmrecovercl.
What is the workaround?
This message is only an auditing message and can be ignored.

no space allowed in file /etc/opt/cmom/cmomhosts directive order setup

What is the problem?
The directive order of order deny,allow or order allow,deny specified in /etc/opt/cmom/cmomhosts does not allow any space between “deny,allow” or “allow,deny”. If the file is not setup properly, nodes that are running monitor packages will not be able to obtain information from other nodes about the cluster status.
What is the workaround?
After Continentalclusters configuration, before the first startup of the monitor package, make sure that the file /etc/opt/cmom/cmomhosts on all of the participating nodes contain the correct directive order specification.

Persistent cmomd Processes

What is the problem? If the node where the monitor process (cmclsentryd) is running goes down and then comes back up (as in a power failure), the cmomd process will remain on one or more nodes in the cluster that is being monitored. In these circumstances, the cmomd process will continue on the system until terminated by a user. This can become a significant problem if a monitoring node is powered off and on several times, leaving several cmomd processes on the monitored cluster, using system process table space as well as other system resources.

What is the workaround? After a failure of the monitoring node, kill the unused cmomd processes.

Provider File Renaming

What is the problem? If the provider file, which is named /opt/cmom/providers/cmprovider.omp by default, is copied to a backup file by adding a prefix to the name (for example, “bk_cmprovider.omp”), then Serviceguard will not be able to tell which file is the correct one.

What is the workaround? Do not rename the provider file to a different name by adding a prefix. As an alternative, you can store copies or alternate versions of the file in a different directory.

Applications hang when all PV links are down

What is the problem? When all PV links to a disk array used by a primary or recovery package are down, the package applications accessing that array will hang indefinitely. The applications will not detect an error and cannot be killed. Even running cmhaltpkg will not stop the application.

What is the workaround? The default behavior of LVM is to retry access forever following a failure. There are a number of ways to recover from this application hang problem:

Reboot the node. The package will then move to another node in the cluster.
Fix the problem so that one or more PV Links is restored. The application will then continue normally.
It is also possible to change the default LVM behavior so that it will not retry forever. There is an lvchange option that will establish a timeout value which will cause LVM to return an error to the application if the access to the array has failed and the timeout period has expired. The command uses the following format:
lvchange -t <seconds> /dev/<vgname>/<lvname>
This command must be run from one host, on all logical volumes in the package volume groups. A starting timeout value of 60 seconds is suggested; the timeout must not be set to less than 60 seconds.
Once the lvchange -t command is run on a host, all other hosts will automatically inherit the new timeout value for the logical volumes. You can view the current timeout value by running the lvdisplay command and checking the value listed for “IO Timeout (Seconds)”. If the value is displayed as “default,” then LVM will use the default behavior and retry forever.