<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Reason for Package failure ? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260731#M685149</link>
    <description>I have two HP9000 servers running HP-UX 11.00.&lt;BR /&gt;They are connected together to form a cluster consisting of the two nodes. The servers have 3 shared volume groups , with two disks mirrored disks in each volume group. These shared disks are activated in exclusive mode by the server running the single package at any one time.&lt;BR /&gt;The problem I have is that recently two disks have been replaced in these shared volumes (Each failed disk was in different volume groups) These failed disks were replaced and mirrored of the remaining good disk of the volume group in each case.&lt;BR /&gt;If I manually activate the shared volumes on each of the nodes in turn and view them and their logical volumes in SAM everything looks good.&lt;BR /&gt;However, now .. when restarting the servers, the cluster forms OK and the package appears to start OK... but then the node re-boots with the message "A crucial package has failed" and the package attempts to move to the other node. However, the package then fails in exactly the same way on the new node.&lt;BR /&gt;I have looked at the syslog.log file and the package.cntl.log files... but i cannot see a reason for the package failure.&lt;BR /&gt;Is there somewhere I should be looking in order to determine the reason for the package failure on both nodes ?</description>
    <pubDate>Sat, 30 Aug 2008 22:45:36 GMT</pubDate>
    <dc:creator>Clive Nicholas</dc:creator>
    <dc:date>2008-08-30T22:45:36Z</dc:date>
    <item>
      <title>Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260731#M685149</link>
      <description>I have two HP9000 servers running HP-UX 11.00.&lt;BR /&gt;They are connected together to form a cluster consisting of the two nodes. The servers have 3 shared volume groups , with two disks mirrored disks in each volume group. These shared disks are activated in exclusive mode by the server running the single package at any one time.&lt;BR /&gt;The problem I have is that recently two disks have been replaced in these shared volumes (Each failed disk was in different volume groups) These failed disks were replaced and mirrored of the remaining good disk of the volume group in each case.&lt;BR /&gt;If I manually activate the shared volumes on each of the nodes in turn and view them and their logical volumes in SAM everything looks good.&lt;BR /&gt;However, now .. when restarting the servers, the cluster forms OK and the package appears to start OK... but then the node re-boots with the message "A crucial package has failed" and the package attempts to move to the other node. However, the package then fails in exactly the same way on the new node.&lt;BR /&gt;I have looked at the syslog.log file and the package.cntl.log files... but i cannot see a reason for the package failure.&lt;BR /&gt;Is there somewhere I should be looking in order to determine the reason for the package failure on both nodes ?</description>
      <pubDate>Sat, 30 Aug 2008 22:45:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260731#M685149</guid>
      <dc:creator>Clive Nicholas</dc:creator>
      <dc:date>2008-08-30T22:45:36Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260732#M685150</link>
      <description>Clive,&lt;BR /&gt;&lt;BR /&gt;what do you mean by following&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;package appears to start OK &amp;gt;&amp;gt;&lt;BR /&gt;&lt;BR /&gt;Are you able to see package status running in&lt;BR /&gt;&lt;BR /&gt;cmviewcl -vp pkgname&lt;BR /&gt;or&lt;BR /&gt;cmviewcl -v&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Sat, 30 Aug 2008 23:16:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260732#M685150</guid>
      <dc:creator>Deepak Kr</dc:creator>
      <dc:date>2008-08-30T23:16:34Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260733#M685151</link>
      <description>Also provide version of serviceguard you are using on these nodes.&lt;BR /&gt;&lt;BR /&gt;#swlist |grep -i serviceguard&lt;BR /&gt;also&lt;BR /&gt;#what /usr/lbin/cmcld&lt;BR /&gt;</description>
      <pubDate>Sun, 31 Aug 2008 00:00:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260733#M685151</guid>
      <dc:creator>Deepak Kr</dc:creator>
      <dc:date>2008-08-31T00:00:56Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260734#M685152</link>
      <description>Have you changed the disk that was in clusterlock vg?&lt;BR /&gt;</description>
      <pubDate>Sun, 31 Aug 2008 00:12:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260734#M685152</guid>
      <dc:creator>Deepak Kr</dc:creator>
      <dc:date>2008-08-31T00:12:16Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260735#M685153</link>
      <description>&lt;!--!*#--&gt;Thanks for your responses and help KumarD.&lt;BR /&gt;With the cluster of both nodes up i can manually start the package (the package is named "package") on a node by entering:&lt;BR /&gt;# cmrunpkg package&lt;BR /&gt;The response is "cmrunpkg completed successfully on all packages specified"&lt;BR /&gt;If I quickly enter "cmviewcl -vp package" at this time I see the following response&lt;BR /&gt;&lt;BR /&gt;PACKAGE   STATUS STATE   PKG_SWITCH    NODE&lt;BR /&gt;package    up   running  disabled     kwamc0s&lt;BR /&gt;&lt;BR /&gt;Policy Parametrs&lt;BR /&gt;POLICY NAME      CONFIGURED_VALUE&lt;BR /&gt;Failover          configured_node&lt;BR /&gt;Failback          manual&lt;BR /&gt;&lt;BR /&gt;Script_Parameters&lt;BR /&gt;ITEM  STATUS  MAXRESTARTS   RESTARTS  NAME&lt;BR /&gt;Service up        0            0      cmsmgr&lt;BR /&gt;Service up        0            0      ovdm&lt;BR /&gt;Service up        0            0      tmn&lt;BR /&gt;Service up        0            0      oracle&lt;BR /&gt;Service up        0            0      neos&lt;BR /&gt;Service up        0            0      lms&lt;BR /&gt;Service up        0            0      shut&lt;BR /&gt;Subnet  up                          128.4.0.0&lt;BR /&gt;Subnet  up                        192.168.1.0&lt;BR /&gt;&lt;BR /&gt;Node_Switching_Parameters&lt;BR /&gt;NODE_TYPE STATUS  SWITCHING    NAME&lt;BR /&gt;Primary     up     enabled kwamc0s (current)&lt;BR /&gt;Alternate   up     enabled kwamc1s&lt;BR /&gt;&lt;BR /&gt;.... So at this point everything looks OK (neos and lms are our two custom application programs) and the package looks to be up and running to me.&lt;BR /&gt;But aftr a few seconds the message appears:&lt;BR /&gt;kwamc0s  cmcld: Halting kwamc0s to preserve data integrity&lt;BR /&gt;Reason: A crucial package failed.</description>
      <pubDate>Sun, 31 Aug 2008 08:43:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260735#M685153</guid>
      <dc:creator>Clive Nicholas</dc:creator>
      <dc:date>2008-08-31T08:43:16Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260736#M685154</link>
      <description>&lt;!--!*#--&gt;#swlist |grep -i serviceguard reports the following:&lt;BR /&gt;PHSS_17581 1.0 MC ServiceGuard 11.05 Cummalative Patch&lt;BR /&gt;&lt;BR /&gt;#what /usr/lbin/cmcld reports the following:&lt;BR /&gt;HP92453-02A.10.20 HP_UX SYMBOLIC DEBUGGER (END.0) $Revision 7403 $&lt;BR /&gt;Build Date: Wed mar 3 14:17:00 PST 1999&lt;BR /&gt;Build id: ibld_sg_a1105_patch&lt;BR /&gt;A.100.05 Date 99/02/22 PHSS_17581 (SG English/Japanese) PHSS_17483(LM English) PHSS_17484 (LM Japanese) Date: 99/01/13 PHSS_17230&lt;BR /&gt;Daemon&lt;BR /&gt;Config DB&lt;BR /&gt;Cluster Monitor&lt;BR /&gt;Command Srv&lt;BR /&gt;CommunicationSrv&lt;BR /&gt;Config&lt;BR /&gt;Dlm&lt;BR /&gt;Local Comm&lt;BR /&gt;Network Sensor&lt;BR /&gt;Package Manager&lt;BR /&gt;Remote Comm&lt;BR /&gt;API&lt;BR /&gt;Service Sesor&lt;BR /&gt;Cluster LVM&lt;BR /&gt;Status DB&lt;BR /&gt;Sync&lt;BR /&gt;Util&lt;BR /&gt;A.01.01 Resource Monitor API (11_00_AR: Oct 17 1997 09:24:32)&lt;BR /&gt;</description>
      <pubDate>Sun, 31 Aug 2008 08:53:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260736#M685154</guid>
      <dc:creator>Clive Nicholas</dc:creator>
      <dc:date>2008-08-31T08:53:42Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260737#M685155</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;All software within this installation is out of date and support.&lt;BR /&gt;&lt;BR /&gt;That being said, the package seems to be shut down to to concerns about data integrity on shared storage.&lt;BR /&gt;&lt;BR /&gt;You need to check all lock disks and shared disks configured within packages and configurations for trouble.&lt;BR /&gt;&lt;BR /&gt;dmesg to start, perhaps disk exercise with mstm/cstm/xstm (your choice) to find the root of the problem.&lt;BR /&gt;&lt;BR /&gt;It would not hurt to plan to bring this cluster back into the world of supported OS/system software and perhaps gain help from your HP Software service contract.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Sun, 31 Aug 2008 09:01:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260737#M685155</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2008-08-31T09:01:42Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260738#M685156</link>
      <description>Yes I believe the disk was changed that contained the clusterlock (Note the servers aren't actually in my station... I am helping out a colleage with these servers by remotely logging-in via the network to the servers in the Netherlands).&lt;BR /&gt;However, i had wondered about the clusterlock before and I think we have performed the correct procedure to ensure that the clusterlock is recreated correctly.&lt;BR /&gt;What I did was this:&lt;BR /&gt;cmhaltcl&lt;BR /&gt;vgchange -c n vg04&lt;BR /&gt;vgchange -c n vg05&lt;BR /&gt;vgchange -a y vg04&lt;BR /&gt;vgchange -a y vg05&lt;BR /&gt;cd /etc/cmcluster&lt;BR /&gt;&lt;BR /&gt;I then did the cmapplyconf command to recompile and distribute the package, before deactivateing the volume groups and running the cluster again.&lt;BR /&gt;&lt;BR /&gt;So, I believe the clusterlocks are OK, but is there a way to check this for sure?&lt;BR /&gt;&lt;BR /&gt;Note: I have remotely logged into kwamc0s with a seperate console and I used the command&lt;BR /&gt;#tail -f /var/adm/syslog/syslog.log&lt;BR /&gt;to follow events in this log when the package is started on kwamc0s.&lt;BR /&gt;I see the line&lt;BR /&gt;cmcld: Service PKG*3841 terminated due to an exit(0)&lt;BR /&gt;&lt;BR /&gt;However, this line appears immediately BEFORE the line shown below with the same timestamp which says:&lt;BR /&gt;cmcld: Started package package on node kwamc0s&lt;BR /&gt;I've no idea why the package is failing and rebooting the node.</description>
      <pubDate>Sun, 31 Aug 2008 09:11:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260738#M685156</guid>
      <dc:creator>Clive Nicholas</dc:creator>
      <dc:date>2008-08-31T09:11:56Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260739#M685157</link>
      <description>Thanks for your help Steven .. I will try what you suggest to check the shared disks.&lt;BR /&gt;I think the problem with support is that the applications being run use HP Openview DM TMN and support for this has been discontinued by HP. The servers help supervise an older submarine cable system and there is no means to update the application software, so the OS has not been touched for many years an we would not be permitted to upgrade it (by managers on high !). These type of systems are installed and commisioned and then we are not permitted to be upgraded/patch further after the initial commissioning/proving period unless there is an exceptional requirement and proof that any work will not affect current custom built application software.</description>
      <pubDate>Sun, 31 Aug 2008 09:26:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260739#M685157</guid>
      <dc:creator>Clive Nicholas</dc:creator>
      <dc:date>2008-08-31T09:26:09Z</dc:date>
    </item>
    <item>
      <title>Re: Reason for Package failure ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260740#M685158</link>
      <description>Clive try following regarding cluster lock disk::&lt;BR /&gt;&lt;BR /&gt;Run &lt;BR /&gt;# cmapplyconf -v -C /etc/cmcluster/cluster-configfilename&lt;BR /&gt;&lt;BR /&gt;and then start package.&lt;BR /&gt;&lt;BR /&gt;I guess this could be due to missing lock info on newly replaced disk.&lt;BR /&gt;&lt;BR /&gt;or &lt;BR /&gt;&lt;BR /&gt;If any previous backup is exists for lock vg configuration then&lt;BR /&gt;&lt;BR /&gt;#vgcfgrestore -n /dev/lock-vg-name disk-device-name&lt;BR /&gt;example&lt;BR /&gt;&lt;BR /&gt;#vgcfgrestore -n /dev/vg_lock /dev/dsk/c4t6d0&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Yes, it is absolutely true that serviceguard version you are running is no more supported by HP.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Sun, 31 Aug 2008 12:09:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/reason-for-package-failure/m-p/4260740#M685158</guid>
      <dc:creator>Deepak Kr</dc:creator>
      <dc:date>2008-08-31T12:09:29Z</dc:date>
    </item>
  </channel>
</rss>

