Bug 425911

Summary: GFS1 with GULM fails to get a posix lock correctly.
Product: [Retired] Red Hat Cluster Suite Reporter: Norm Murray <nmurray>
Component: gulmAssignee: Chris Feist <cfeist>
Status: CLOSED NOTABUG QA Contact: Cluster QE <mspqa-list>
Severity: low Docs Contact:
Priority: low    
Version: 4CC: Chris.Verhoef, cluster-maint, swhiteho, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-06 15:57:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test lock file none

Description Wade Mealing 2007-12-17 07:16:59 UTC 
Description of problem:

After a few tries, when using GFS1 on a GULM managed RHEL4 cluster server, the
posix lock server fails.  The gulm_plock function seems to return -11 (EAGAIN
consistantly, but an event will/can flush the locks eventually.


Version-Release number of selected component (if applicable):

gulm-1.0.10-0

kernel-2.6.9-55.0.12.EL

How reproducible:




Steps to Reproduce:
1. Run attached test program between 1 and 100 times.  
2. Note that the lock code returns back -11 (eagain) 
  
Actual results:

Posix unlock gets called all the way down to gulm_punlock, when a re-lock
attempts to be called, the error is set accordingly, I can't determine
what exactly sets the error message.


Expected results:

Lock requests to complete.

Additional info:

Customer is tied to gulm on this environment, unwilling to change to DLM due to
testing requirements.  Locking program to be attached.
Comment 1 Wade Mealing 2007-12-17 07:19:44 UTC 
[root@r4-2 gfs]# ./filetest tmpfile111.tmp
Opening handle for file: tmpfile111.tmp
Trying to acquire file lock!
Lock obtained!
Terminate with ^C for ungraceful shutdown or enter to continue.
^[[A
Shut down gracefully!
[root@r4-2 gfs]# ./filetest tmpfile111.tmp
Opening handle for file: tmpfile111.tmp
Trying to acquire file lock!
Lock obtained!
Terminate with ^C for ungraceful shutdown or enter to continue.

[root@r4-2 gfs]# ./filetest tmpfile111.tmp
Opening handle for file: tmpfile111.tmp
Trying to acquire file lock!
Lock obtained!
Terminate with ^C for ungraceful shutdown or enter to continue.
^[[A
Shut down gracefully!
[root@r4-2 gfs]# 
[root@r4-2 gfs]# ./filetest tmpfile111.tmp
Opening handle for file: tmpfile111.tmp
Trying to acquire file lock!
Lock obtained!
Terminate with ^C for ungraceful shutdown or enter to continue.
^[[A
Shut down gracefully!
[root@r4-2 gfs]# ./filetest tmpfile111.tmp
^[[AOpening handle for file: tmpfile111.tmp
Trying to acquire file lock!
Error from fcntl() for file locking: 11
[root@r4-2 gfs]# ./filetest tmpfile111.tmp
Comment 2 Wade Mealing 2007-12-17 07:20:44 UTC 
Created attachment 289750 [details]
Test lock file
Comment 3 RHEL Program Management 2007-12-17 07:25:34 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 6 Steve Whitehouse 2008-12-10 16:32:09 UTC 
There seems to be no recent activity on this bug. Can we close it?