Bug 129704

Summary: when locking Packages file error message gives wrong reason
Product: [Fedora] Fedora Reporter: Enrique Perez-Terron <enrio>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Mike McLean <mikem>
Severity: low Docs Contact:
Priority: medium    
Version: 2CC: mattdm, nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-25 20:25:52 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
Suggested patch none

Description Enrique Perez-Terron 2004-08-11 22:04:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7)
Gecko/20040615 Firefox/0.9

Description of problem:
When trying to run rpm while another process is running an rpm
transaction, the error messages are:

  error: cannot get shared lock on /var/lib/rpm/Packages
  error: cannot open Packages index using db3 - Operation not
permitted (1)
  error: cannot open Packages database in /var/lib/rpm

In this message, the last part of the middle line is the result of
calling strerror(rc), where rc has been set to 1 rather than to errno,
independently of the nature of the failure.

This error message is misleading aas to the cause of the failure.

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

How reproducible:
Always

Steps to Reproduce:
1. Due to the timing constraints, I suggest you compile the following
   C program with "gcc -o lock lock.c":
-----------------------8<-----------------------------
#include <unistd.h>
#include <fcntl.h>
 
int main(int argc, char *argv[])
{
    int fd = open(argv[1], O_RDWR, 0666);
    if (fd < 0) {
        perror("open");
        exit(1);
    }
    struct flock l;
    bzero(&l, sizeof(l));
    l.l_type = F_WRLCK;
    int ret = fcntl(fd, F_SETLK, &l);
    if (ret < 0) {
        perror("fcntl");
        exit(1);
    }
    sleep(30);
    exit(0);
}
-----------------------8<-----------------------------
2. ./lock /var/lib/rpm/Packages & sleep 2; rpm -e non-existent-package
3.
    

Actual Results:  
error: cannot get shared lock on /var/lib/rpm/Packages
error: cannot open Packages index using db3 - Operation not permitted (1)
                                              ^^^^^^^^^^^^^^^^^^^^^^^ ^^^
error: cannot open Packages database in /var/lib/rpm
error: package non-existent-package is not installed


Expected Results:  The underlined part of the error message should
read "Resource temporarily unavailable (11)" or "Permission denied
(13)" depending on whether the call to fcntl() sets errno to EAGAIN or
EACCESS.

Additional info:

Comment 1 Enrique Perez-Terron 2004-08-11 22:13:22 UTC
Created attachment 102638 [details]
Suggested patch

The patch affects return value of the function db3open() in rpmdb/db3.c.
This function is called from dbiOpen() in rpmdb/rpmdb.c, where the return
value is used in a call to strerror().

The original code sets the return value to 1 independently of the nature of the
failure, while my patch sets it equal to the value of errno.

Comment 2 Jeff Johnson 2005-02-07 22:11:25 UTC
fcntl locking on Packages uses the Berkeley DB method
to get a fdno for locking, which happens to be
the fdno of the 1st opened database iirc.

All you want is errno returned inline? That does not
follow existing (albeit glacial) progress to unifying
all synchronous rpm error codes to conform to
   RPMRC_OK = 0,
   RPMRC_NOTFOUND = 1, (which is consistent with return 1)

The real problem is the error msg, not the return code.,
as errno can always be accessed by the caller.

"Operation not permitted" is perhaps semantically
correct even if not useful for diagnosing the
details of a problem.

I'll diddle up a fix for the error message to display
errno instead.

Comment 3 Matthew Miller 2005-04-26 15:35:06 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 4 John Thacker 2006-10-25 20:25:52 UTC
Closing per previous comment and lack of response.  Also note that FC1 and FC2
are no longer supported even by Fedora Legacy.