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.
Created attachment 132204 [details] First program to run
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)
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
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.
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