cluster AUTO_RUN DISBLED

[Lissete Calderón]

Hi team,
I already configured a two nodes cluster with MC SGuard ver 11.16 , but qhen a failover ocurrs the only pakage does not switch to the other node , even if the pkg1.config has the AUTO_RUN variable as YES , I already check the package configuration and is already applied , but does not work?

Do I have to recompile the entire cluster?
Do I have to recompile the pkg1 in both nodes, one by one?

Please some body help me?

Thanks in advance for your help.

Nancy

PS I attached some files.

PACKAGE STATUS STATE AUTO_RUN NODE
pkg1_gcota down halted disabled unowned

[Mel Burslan]

according to the cmviewcl -v output in the attachment, the package should failover to the secondary node and even, in my opinion, it is bad, it can automatically fail back to the primary node without any human intervention should it fail on the secondary node at any time.

do you see that it is just halting the package when a failure occurs or is it trying to start and failing to initialize the package and fails into a halted state ?

another good attachment would be the log file in /etc/cmluster/pkg1 directory, i.e. /etc/cmluster/pkg1/*log, from both gemota1 and gemota2 nodes.

[Chan 007]

Hi,

1. Try to failover the package alone manually.
halt the pkg on the primary node and start on the secondary node. Check for any errors.

This can be found where you configured the cluster log, also in the /var/adm/syslog/syslog.log.

2. We need the cluster log or syslog to analyze.

3. use tail -f to the logs while doing halt and start so that you get idea, what is wrong.

cheers...007

[Jayasuntar]

Dear Lissete,

Not only the AUTO RUN and the node switching parameters decides to run the package in configured node.

Please post your syslog and the pkg.cntl.log file. There you can really see what is happening on switchover.

For your information, if the pkg is not halted properly, this will not switch over to another node. Please chek the log for details

Regards

Jay

[RAC_1]

Is package swtiching enabled?? cmmodpkg -ev "pkg_name" to do that.

cmviewcl -p "pkg_name" -v to check it.

[Mark Nieuwboer]

Hi Lissete,

I thing the problem is what RAC was saying.
After you start the package for the first time you have to do a cmmodpkg -e pkg_name to make the package aware that it can failiver.
see man cmmodpkg.

grtz. Mark

[Mohanasundaram_1]

Hi Lissete,

I found this in your pkg1.sh

LV[1]=/dev/vg01/lvol1; FS[1]=/database1; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

Your problem is the indexing number.
note: this line should read like this,

LV[1]=/dev/vg01/lvol1; FS[1]=/database1; FS_MOUNT_OPT[1]="-o delaylog";
FS_UMOUNT_OPT[1]=""; FS_FSCK_OPT[1]=""; FS_TYPE[1]="vxfs"

there are many such lines with the same mistake. I wonder how you started the package with this mistake. the filesystem mounting should have failed. Please rectify this and copy the same to the other node.

Then start your package.

With regards,
Mohan.

[Stephen Doud]

Mohanasundaram is correct- the package control script that you supplied has bogus LV entries (subscript array values are all 0 (zero)):

LV[0]=/dev/vg09/lvol1; FS[0]=/product; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[1]=/dev/vg01/lvol1; FS[1]=/database1; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[2]=/dev/vg02/lvol1; FS[2]=/database2; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[3]=/dev/vg03/lvol1; FS[3]=/database3; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[4]=/dev/vg04/lvol1; FS[4]=/database4; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[5]=/dev/vg05/lvol1; FS[5]=/database5; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[6]=/dev/vg06/lvol1; FS[6]=/database6; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[7]=/dev/vg07/lvol1; FS[7]=/database7; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

LV[8]=/dev/vg08/lvol1; FS[8]=/database8; FS_MOUNT_OPT[0]="-o delaylog";
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"

However I'm not certain that these entries will cause a package failover failure, since the same entry is valid for every mount point (the values are the same).

I suspect that the package is attempting to start on the adoptive node, but something is causing it to fail to start up cleanly, which triggers Serviceguard to immediately shut down the package.

Check your package control log on the adoptive node to see what it did when it attempts to start the package.

Sometimes you have to look at the syslog.log and package control log on both nodes to get a clear chronology of what took place.