Bug 198303 - fcntl lock doesn't work on local machine when in cluster mode
fcntl lock doesn't work on local machine when in cluster mode
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
4
All Linux
high Severity high
: ---
: ---
Assigned To: Abhijith Das
GFS Bugs
:
Depends On:
Blocks: 180185
  Show dependency treegraph
 
Reported: 2006-07-10 18:35 EDT by Rob Kenna
Modified: 2010-01-11 22:12 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0561
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:35:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
First program to run (1.11 KB, text/x-csrc)
2006-07-10 18:35 EDT, Rob Kenna
no flags Details
Second program to run (5.87 KB, text/x-csrc)
2006-07-10 18:37 EDT, Rob Kenna
no flags Details

  None (edit)
Description Rob Kenna 2006-07-10 18:35:34 EDT
Description of problem:  fcntl advisory lock doesn't work on the same machine
when in a clustered configuration


Version-Release number of selected component (if applicable): RHEL 4 U3 & U4


How reproducible: 100%


Steps to Reproduce: 
1. In a clustered config, take an fcntl write lock
2. In a second process on the same machine try to take a write lock
3. The second process sees no lock.
  
Actual results:  Second process does not see the lock take on the first


Expected results: Second process should see that a lock is already taken


Additional info:  Enclosed test programs.
Comment 1 Rob Kenna 2006-07-10 18:35:34 EDT
Created attachment 132204 [details]
First program to run
Comment 2 Rob Kenna 2006-07-10 18:37:56 EDT
Created attachment 132205 [details]
Second program to run

First run test_lock then lock_check, both on the same machine of a clustered
configuration (doesn't fail in nolock mode)
Comment 7 Rob Kenna 2006-07-12 11:54:14 EDT
reproducer:

In a cluster, on the same node run:

lock_test test-file   // test-file is any file on the gfs fs

then on the same node run (before 30 seconds runs out)

lock_check test-file  // should say there is 1 lock present
Comment 8 Abhijith Das 2006-07-12 18:02:50 EDT
Fix committed to CVS, RHEL4, RHEL4U4 and STABLE branches. F_GETLK was broken, in
that it used to always return zero lock conflicts for local locks. Also, the pid
returned by F_GETLK for the local lock-holding process was bogus.
Comment 11 Red Hat Bugzilla 2006-08-10 17:35:55 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0561.html

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