Bug 470274

Summary: Yum tracebacked due to missing file to delete
Product: Red Hat Enterprise Linux 5 Reporter: Lubomir Rintel <lkundrak>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: bperkins, gkhachik, jhutar
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
The rebased code in this version of yum handles the removal of .sqlite files differently from older versions. Previously, yum could crash while completing a transaction if it were still cleaning up the .sqlite file from a previous transaction. This crash cannot happen in the current version of yum.
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 03:33:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Lubomir Rintel 2008-11-06 09:52:46 EST
I have no idea where did /var/cache/yum/epel/primary.sqlite go (I run yum-updatesd, and am not aware of running any other instance of yum at the time this happened), but since it's gone I guess we shouldn't die if we can't delete it.

Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 105, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 293, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 217, in doCommand
    return base.erasePkgs(extcmds)
  File "/usr/share/yum-cli/cli.py", line 674, in erasePkgs
    oldcount = len(self.tsInfo)
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 546, in <lambda>
    tsInfo = property(fget=lambda self: self._getTsInfo(), 
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 91, in _getTsInfo
    self._tsInfo.setDatabases(self.rpmdb, self.pkgSack)
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 537, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 392, in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 242, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 149, in populate
    db_un_fn = self._check_uncompressed_db(repo, mydbtype)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 193, in _check_uncompressed_db
    os.unlink(db_un_fn)
OSError: [Errno 2] No such file or directory: '//var/cache/yum/epel/primary.sqlite'
Comment 1 James Antill 2008-11-06 10:32:01 EST
what command did you run to generate the above?
what version of yum is this (yum --version)?
Comment 2 James Antill 2008-11-06 10:34:07 EST
 I think the problem is:

                if not repo.cache:
                    os.unlink(db_un_fn)

...should be:

                if not repo.cache:
                    try:
                        os.unlink(db_un_fn)
                    except: # Could have an error before anything happens
                        pass

...however this looks like a temporary condition, is that what you are seeing?
Comment 3 Lubomir Rintel 2008-11-06 16:33:04 EST
(In reply to comment #1)
> what command did you run to generate the above?

Removing packages. The exact command was "yum -y remove gdc\*".

> what version of yum is this (yum --version)?

Sorry, I don't know the exact number, since I left my lappy at work, but I am pretty sure it is RHEL 5.3 beta.

(In reply to comment #2)
>  I think the problem is:
> 
>                 if not repo.cache:
>                     os.unlink(db_un_fn)
> 
> ...should be:
> 
>                 if not repo.cache:
>                     try:
>                         os.unlink(db_un_fn)
>                     except: # Could have an error before anything happens
>                         pass

Maybe there should be a check if the file is really gone in the except block; just in case the problem is bad permission or r/o file system or selinux denial or anything like that.

> ...however this looks like a temporary condition, is that what you are seeing?

Yes. Re-running the exactly same command resulted in successful run.
Comment 10 Garik Khachikyan 2009-07-27 11:20:51 EDT
# VERIFIED

Here is the scenario checked:
1. Make a large "alarge.sqlite" file under /var/cache/yum/<channel_name>/, large enough to make some processing time for "yum clean metadata" task in the same directory where another sqlite file exists (e.g.: primary.xml.gz.sqlite)
2. It's important to give the large file a name, coming first in order list of *.sqlite files (to be removed, and delay yum clean process for a while). 
3. While the task is running rm -f primary.xml.gz.sqlite (the second file)

So now the yum does not dies when could not find the file listed during its start but not found during a try of its processing.
The report, containing the number of sqlite files removed, contains also the file actually "not removed" by the "yum clean" process.

So everything looks pretty fine :)

Checked with: RHEL5.4-Client-20090715.0 (i386, x86_64); RHEL5.4-Server-20090715.0 (i386, x86_64, ia64, s390x)
Package: yum-3.2.22-20.el5.noarch
Comment 12 Ruediger Landmann 2009-09-01 02:34:17 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
The rebased code in this version of yum handles the removal of .sqlite files differently from older versions. Previously, yum could crash while completing a transaction if it were still cleaning up the .sqlite file from a previous transaction. This crash cannot happen in the current version of yum.
Comment 13 errata-xmlrpc 2009-09-02 03:33:35 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 therefore 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.

http://rhn.redhat.com/errata/RHBA-2009-1419.html