HP Serviceguard Version A.11.18 Release Notes, September 2008

packages configured for the cluster, not just for the package that was being
configured or deleted via cmapplyconf or cmdeleteconf.
• Resolution: The warnings are now given correctly — only for a package that is
being added or modified.
QXCR1000741571: Hanging node problem causing cluster to go down
• Problem: A hang on one node could cause multiple cluster re-formations, until
eventually the entire cluster failed.
• Resolution: The code has been modified so that a hung node no longer causes this
problem.
QXCR1000746305: Site controller pkg failed to start after cmhaltnode -f
• Problem: When all the nodes on one site were halted with cmhaltnode -f, the
site controller package might not run successfully on the remote site. (This problem
could occur in site-aware disaster-tolerant clusters; see the subsection “For More
Information” (page 42), in the section “About Cross-Subnet Configurations”.)
• Resolution: The site controller package now runs successfully.
QXCR1000747823: cmviewconf does not display managed packages for SC package
• Problem: cmviewconf did not report Managed Packages information for the
site controller package. (This problem could occur in site-aware disaster-tolerant
clusters; see the subsection “For More Information” (page 42), in the section “About
Cross-Subnet Configurations”.)
• Resolution: cmviewconf now reports the information correctly. You can also get
this information by running cmviewcl -v -f line.
QXCR1000749527: cmmakepkg -l does not list non-SG modules
• Problem: The -l option of cmmakepkg should list all modules that can be used to
build a package, but it listed only Serviceguard modules; partner modules such
as the MetroRAC dts/mcsc module were not listed.
• Resolution: cmmakepkg -l now lists all installed modules.
QXCR1000749924: Dependent packages started on non-primary nodes
• Problem: Failover packages which are dependent on a multi-node package may
start on a node other than their primary node even though the dependency is met
on the primary node.
• Resolution: The code behaves as designed. To ensure a dependent package runs
on its primary node whenever possible, set its failback_policy to automatic, so
that if the package starts on a non-primary node, it will be automatically failed
back as soon as the primary node is available. For more information, see “About
Multi-Node Packages” (page 38).
Fixed in This Version 83