Bug 128104 - Lockfiles are erroneously removed while locking process still exists
Lockfiles are erroneously removed while locking process still exists
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: lockdev (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
Depends On:
Blocks: 187539
  Show dependency treegraph
Reported: 2004-07-17 16:02 EDT by Radu Rendec
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2006-0405
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-10 17:39:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
level 1 patch made against already patched (1.0.1-1.3) source tree (1.46 KB, patch)
2004-07-17 16:06 EDT, Radu Rendec
no flags Details | Diff

  None (edit)
Description Radu Rendec 2004-07-17 16:02:15 EDT
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 16:06:47 EDT
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 12:28:48 EDT
this is a good patch. goes across cleaning against all our arches--
code looks sane. thanks.
Comment 12 Red Hat Bugzilla 2006-05-10 17:39:30 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.