Bug 103674

Summary: fcntl database locking doesn't work
Product: [Retired] Red Hat Linux Reporter: Michael Schröder <mls>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: GinGin64   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-09-15 03:22:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch none

Description Michael Schröder 2003-09-03 19:11:05 UTC 
fcntl database locking is broken. The Packages database is locked once
at the start of rpm when dependency checking is done (db opened rdonly).
If everything is ok, the database is closed and re-opened rw. The problem
is that the db->close() closes the filedescriptor, and thus the fcntl
lock is lost.
Comment 1 Michael Schröder 2003-09-03 19:12:11 UTC 
Created attachment 94176 [details]
proposed patch
Comment 2 Jeff Johnson 2003-09-10 14:03:11 UTC 
Yup.

The more general question is:
    Does SuSE need fcntl exclusive locking?
The concurrent locking is reliable and sufficient (for rpmdb,
install/erase locking is different problem) afaict, and I'd
like to eliminate legacy code.
Comment 3 Michael Schröder 2003-09-10 15:57:05 UTC 
Good question. The current code selects it as we don't have nptl.
"unshared posix mutexes found, adding DB_PRIVATE, using fcntl lock"
Comment 4 Jeff Johnson 2003-09-15 03:22:42 UTC 
This is a run time test for nptl in rpmdb/db3.c.

If you don't have nptl, then you should eliminate the test,
and compile without --enable-posixmutexes (2 occurences,
autogen.sh and rpm.spec).

You will lose unified thread/process locks but that should not mattter,
the CDB locks will work fine.
Comment 5 Michael Schröder 2003-09-15 09:50:10 UTC 
Uh, this *is still* a bug. If you really think it isn't you should throw
out the fcntl locking code, because it doesn't work.
Comment 6 Jeff Johnson 2003-09-15 16:33:07 UTC 
Yes, fcntl locking is being phased out.

And the real bug is that reopening O_RDWR opens a locking
window, not anything else.