Operating System - HP-UX
1826188 Members
2631 Online
109691 Solutions
New Discussion

Re: NFS lockd issue 11iv3 & redhat linux AS

 
SOLVED
Go to solution
rochelle lauer
Occasional Contributor

Re: NFS lockd issue 11iv3 & redhat linux AS

Hello

Yes, I am running the latest ONCplus.

I installed the latest ONCplus
when I started to "revisit" this issue
because we needed to go to Java 1.6
(I previously forced Java 1.5 on our users)

After looking over all the emails from
my previous support calls I am not
sure it is Java. Perhaps HP-UX is
misinterpreting the lock request.

--rochelle
Dave Olker
Neighborhood Moderator

Re: NFS lockd issue 11iv3 & redhat linux AS

I'm not clear on why HP support can't identify this problem? Have you collected "good" and "bad" data for them that shows the problem? If an application is sending lock requests in a loop that's not really KLM's fault, but if KLM is not processing locks correctly that is our fault.

If you haven't already, I would collect a debug KLM log file from the working case and the failing case along with a nettl trace of the failing case and have HP support analyze them to determine if it's the RH client at fault or the HP server.

Dave


I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
wvsa
Regular Advisor

Re: NFS lockd issue 11iv3 & redhat linux AS

Hello David;

Well it looks like others have joined in the journey. It appears that after applying the following patch bundle:

contents PHCO_40211,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_36261,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_38040,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_38080,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_38681,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_38691,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_38746,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39328,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39398,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_39399,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_39476,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39509,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39594,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39606,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_39740,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40136,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40205,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40209,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40210,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40273,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40293,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40297,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40427,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40431,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40434,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40435,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40459,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40531,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_40938,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40939,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40940,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHKL_40963,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_41008,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHKL_41355,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHSS_39886,r=1.0,a=HP-UX_B.11.11_32/64,v=HP
contents PHSS_39887,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP
contents PHSS_41099,r=1.0,a=HP-UX_B.11.31_IA,v=HP
contents PHSS_41168,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
contents PHSS_41179,r=1.0,a=HP-UX_B.11.31_IA/PA,v=HP
end


and rebooting the servers we applied the patch depot to, lockmgr came up during the boot with no problem. Prior to applying this patch depot lockmgr would not start during the boot process. We applied the patches on 9/3 and checked lockmgr this morning and lockmgr was still running as a matter of fact it is still running on all of our hpux servers. So it appears the patch depot may have fixed the startup problem although none of the patches don't appear to have anything to do with lockmgr. I obtained the list of patches from swa, we updated swa and these patches appeared on our swa reports.

I took a look at the rc.log on the one server we had problems with and rc.log indicated that lockmgr did start, there were no error messages.

At this point I'm not sure where we go except to monitor the lockmgr process and try to catch when it goes down, perhaps a script in cron to monitor

Let me know if you have any thoughts.


Norm