Bug 129704 - when locking Packages file error message gives wrong reason
Summary: when locking Packages file error message gives wrong reason
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 2
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-11 22:04 UTC by Enrique Perez-Terron
Modified: 2008-08-02 23:40 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-25 20:25:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Suggested patch (436 bytes, patch)
2004-08-11 22:13 UTC, Enrique Perez-Terron
no flags Details | Diff

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.


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