Bug 425911 - GFS1 with GULM fails to get a posix lock correctly.
Summary: GFS1 with GULM fails to get a posix lock correctly.
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gulm (Show other bugs)
(Show other bugs)
Version: 4
Hardware: All Linux
low
low
Target Milestone: ---
Assignee: Chris Feist
QA Contact: Cluster QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-17 07:16 UTC by Norm Murray
Modified: 2018-10-27 14:43 UTC (History)
4 users (show)

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: ---


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

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 Product and 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?


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