Bug 111918 - NFS advisory file locks not correctly cleaned up when client process aborts
NFS advisory file locks not correctly cleaned up when client process aborts
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-12-11 11:03 EST by Angus Thomas
Modified: 2007-11-30 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:23:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Angus Thomas 2003-12-11 11:03:35 EST
Description of problem:

Using advisory locking on NFS mounts from a NetApp filer, locks are
released cleanly if the process locking the file exits normally.
However, if the process aborts, the lock is not reliably removed.

Version-Release number of selected component (if applicable):

Tested in RH9 and also with AS 2.1 2.4.9-e12 enterprise

How reproducible:
Code to shoe the problem, and a proposed patch, are available at 

Steps to Reproduce:
1. Run application which uses advisory locking to lock a file from a
remote NFS server
2.  Kill application
Actual results:
The record of the file lock is not released.

Expected results:
The file lock should be released when the process holding the lock exits.

Additional info:

Additional discussion of this issue:
The original report is at

Further discussion is at
Comment 1 Michael Tonn 2005-06-08 12:15:12 EDT
I have experienced this same problem running Oracle RAC on RHEL3 Update 4.  
The database would not restart due to the existence of the stale locks.
Comment 2 Michael Glasgow 2005-10-03 14:04:39 EDT
We fixed this by starting statd with -n $HOSTNAME while HOSTNAME was set to the 
simple hostname in /etc/sysconfig/network.  For some reason, statd was using 
the FQDN while the filer wanted to see the simple hostname.
Comment 3 RHEL Product and Program Management 2007-10-19 15:23:38 EDT
This bug is filed against RHEL2.1, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products.  Since
this bug does not meet that criteria, it is now being closed.

For more information of the RHEL errata support policy, please visit:

If you feel this bug is indeed mission critical, please contact your
support representative.  You may be asked to provide detailed
information on how this bug is affecting you.

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