Bug 425911 - GFS1 with GULM fails to get a posix lock correctly.
GFS1 with GULM fails to get a posix lock correctly.
Status: CLOSED NOTABUG
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gulm (Show other bugs)
4
All Linux
low Severity low
: ---
: ---
Assigned To: Chris Feist
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-17 02:16 EST by Norm Murray
Modified: 2010-10-22 17:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 11:57:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test lock file (1.17 KB, text/x-csrc)
2007-12-17 02:20 EST, Wade Mealing
no flags Details

  None (edit)
Description Wade Mealing 2007-12-17 02:16:59 EST
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 02:19:44 EST
[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 02:20:44 EST
Created attachment 289750 [details]
Test lock file
Comment 3 RHEL Product and Program Management 2007-12-17 02:25:34 EST
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 11:32:09 EST
There seems to be no recent activity on this bug. Can we close it?

Note You need to log in before you can comment on or make changes to this bug.