Bug 128104

Summary: Lockfiles are erroneously removed while locking process still exists
Product: Red Hat Enterprise Linux 3 Reporter: Radu Rendec <radu.rendec>
Component: lockdevAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: poelstra
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: RHBA-2006-0405 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-10 21:39:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 187539    
Description Flags
level 1 patch made against already patched (1.0.1-1.3) source tree none

Description Radu Rendec 2004-07-17 20:02:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040706 Firefox/0.9.1

Description of problem:
Lock files created under /var/lock are erroneously removed under
certain circumstances.

Lock files should be removed by a process trying to acquire the lock,
if the locking process is not alive any more. However, the test
against the existing process id is broken, resulting in an abnormal

Particularly, the kill() system call is used to determine whether a
process id (pid) still exists or not. The problem is that the only
check is made against the return value, which is expected to be 0 if
kill() succeeds and -1 otherwise. However, a failure of kill() does
not necessarily mean that the pid does not exist; it may also mean
that the calling uid doesn't have permission to kill() the specified pid.

I fixed the bug, and a patch is available at:

Please consider checking the patch and including it in the official

I also made a patch against the package spec file, which you might
find useful. It's available at:

Should you have any questions or comments regarding this issue, please
do not hesitate to contact me.

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

How reproducible:

Steps to Reproduce:
1.Lock a device as root
2.Try to lock the same device as unprivileged user


Actual Results:  The lockfiles created at step 1 are replaced by new
lockfiles. The process running as unprivileged user thinks the process
running as root is dead, because it can't be killed.

Expected Results:  The process running as unprivileged user should not
have been able to acquire the lock.

Additional info:

Comment 1 Radu Rendec 2004-07-17 20:06:47 UTC
Created attachment 102008 [details]
level 1 patch made against already patched (1.0.1-1.3) source tree

Merely tested by me on an i386 architecture. Although I don't think it is
architecture-dependant, it probably needs more testing.

Comment 2 Eido Inoue 2004-10-22 16:28:48 UTC
this is a good patch. goes across cleaning against all our arches--
code looks sane. thanks.

Comment 12 Red Hat Bugzilla 2006-05-10 21:39:30 UTC
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.