Messaging Server Will Not Start after Patching Cluster to 3.3u2
(Doc ID 1592177.1)
Last updated on DECEMBER 19, 2024
Applies to:
Oracle Communications Messaging Server - Version 7.0.0 and laterInformation in this document applies to any platform.
Symptoms
Messaging Server works properly (in and out of cluster) on node 2 of the cluster.
Messaging Server can be started manually (out of cluster) on node 1 of the cluster.
But, the cluster is unable to start Messaging on node 1.
The only messages regarding the problem are like:
Cluster.RGM.global.rgmd: [ID 922363 daemon.notice] resource ims-res status msg on node node1 change to <Starting>
Cluster.RGM.global.rgmd: [ID 529407 daemon.notice] resource group comms-rg state on node node1 change to RG_PENDING_ONLINE
Cluster.RGM.global.rgmd: [ID 443746 daemon.notice] resource ims-res state on node node1 change to R_STARTING
Cluster.RGM.global.rgmd: [ID 443746 daemon.error] resource ims-res state on node node1 change to R_START_FAILED
Cluster.RGM.global.rgmd: [ID 784560 daemon.notice] resource ims-res status on node node change to R_FM_FAULTED
The above are reported on the node which is president at the time. They show it tried to start Messaging on node1 but failed.
The normal "launching method..." and "method ... completed..." messages, which should have appeared on the node where it was trying to start the application, did not appear.
Enabling additional debugging as described in How to Enable Debugging on Sun Cluster, provided no additional information.
It seems as if the cluster is not even trying to run the ims_svc_start method even though it is able to start other resources on which Messaging depends.
(C480783) Error: For resource_security value <SECURE>, the executable path
/opt/sun/comms/msg_scha/bin/ims_svc_validate
is insecure because it is owned or writable by a non-root user.
(C720144) Validation of resource mailserver64-ar in resource group MS_RG on node xxx failed.
Changes
OS and cluster patches were installed, bringing node1 from Sun Cluster 3.3 to 3.3u2.
But node2 was not patched - because they did not want to proceed with patching node2 when it seemed patching caused this problem on node1.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Symptoms |
Changes |
Cause |
Solution |
References |