HP-UX HB v13.00 Ch-15 - Serviceguard

HP-UX Handbook Rev 13.00 Page 87 (of 108)
Chapter 15 Serviceguard
October 29, 2013
# what /usr/lbin/identd
usr/lbin/identd:
$Revision identd 2.7.4 (PHNE_26305) $
If the version is not sufficient you need to update to a later version of sendmail.Also
make sure that you run ARPA patch PHNE_31247 for HPUX 11.11 or later or
PHNE_24715 on HPUX 11.00.
14. If the Strong Random Number Generator is installed make sure you run version
B.11.11.07 or later.
# swlist -l bundle | grep KRNG
KRNG11i B.11.11.09 HP-UX 11.11 Strong Random Number Generator
Also make sure the /dev/random and /dev/unrandom device files have a major number
matching the "rng" driver:
# ls -l /dev/*random
cr--r--r-- 1 bin bin 62 0x000000 Nov 19 18:09 /dev/random
cr--r--r-- 1 bin bin 62 0x000001 Nov 19 18:09 /dev/urandom
# lsdev | grep 62
62 -1 rng pseudo
15.
a. Make sure that the number of Serviceguard commands running in parallel is not
too high. Often users run cmviewcl in shell scripts to automate status monitoring.
This can lead to problems when the requests cannot be answered quickly enough.
You can check this by determining how long cmclconfd -p (not the ones with -c!)
is running already (use ps -ef). If cmclconfd -p runs for a long time already (days
or even weeks) this is an indicaton that many Serviceguard commands are
executed on the cluster (not only the local node) in parallel. Also high CPU usage
of cmclconfd -p and/or cmcld could be an indicator for this (run top(1m) to
verify). Read HA Products Newsletter #50 (HP internal), 1st article. Also read
HA Products Newsletter #59 (HP internal), 3rd article, for a known problem
caused by Openview Operations agents.
b. If the CPU usage of cmclconfd -p is low and there is no indication of many
SERVICEGUARD commands being executed, but cmclconfd -p already runs for
a long time, it might be that cmclconfd is hung. To kill it and to get a core file of
cmclconfd, kill it with signal SIGABRT (kill -SIGABRT <pid_of_cmclconfd_-
p>). cmclconfd would automatically be restarted by the next Serviceguard
command requesting it.