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
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
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:
Last Closed: 2006-08-10 17:35:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

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.


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