cmcheckconf freeze

[Mahendra Luhar]

Operating MC/Serviceguard version A11.14 between a K580/4 and a K360/4, HPUX11.00.
The cluster is up,running a package on the K580 the K360 is purely standby at the present time.
I want to add a couple of packages to the cluster. When a cmcheckconf command is issued to verify the config no response is generated after "Begin cluster verification..." the longest I've left it is 20minutes before issuing a ctrl C interrupt.
I noticed a number of "cmclconfd -c " entries generated by inetd when a ps -ef|grep cmc was issued.
Any ideas on what's going ?

[BFA6]

Hi,

Have you tried running cmscancl to see what information this brings back. Have a look at the man page for it.

Hilary

[melvyn burnard]

well a little more detail might help. what sort of storage, what networks and how many.
You could try to ue the -k option to eliminate some disk probing.
I have often seen issues like this where there are eihter network problems, especially nakme resolution, or there have been scenarios where there are PV's known about by lvm, .g. in lvmtab, but htey do not actually exist,. What happens here is that the system goes off to scan every PV it thinks it knows about, and if there is no disc, it sits until it hits the pv timeout, of around 2 minutes per disc.

One way around this is to ensure your cluster ascii file has all the shared vgs within the cluster specifed, I have seen that speed things up.
Just a few thought

[Ashwani Kashyap]

I have seen this problem arising mostly due to name resolution problems or network problems .

A good way is to run cmscancl and verify the output against your actual setup .

Also first try running cmcheckconf for the cluster ascii file only . If it passes then do it again for the package conf file only . If that passes to it togther . The results of the three may give you several clues .

As far as cmclconf -d goes . I don't know what your number is . but I have several 2 node cluster and each node has 2 , cmclconfd -c daemons running . I guess it depends on the number of nodes in the cluster , but i am not sure .

[Dietmar Konermann]

Hi!

I really often saw such symptoms with cmclconfd processes being stuck during disk probing. You should have a look at the cmclconfd's priorities using "ps -el". Watch out for PRIO 148, typically for IO. Looking at the proc's open files (with Glance or lsof e.g.) should show the offending disk device then. Try to read it with e.g. dd then.

Regards...
Dietmar.

[Mahendra Luhar]

There was an issue with a disk mechanism within the vg00 group. Once this was rectified normal operation was restored with regards cmcheckconf.

[Martin Johnson]

Thanks for taking the time to explain the resolution.

Marty