Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Yum tracebacked due to missing file to delete|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Lubomir Rintel <lkundrak>|
|Component:||yum||Assignee:||James Antill <james.antill>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||5.3||CC:||bperkins, gkhachik, jhutar|
|Fixed In Version:||Doc Type:||Bug Fix|
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.
|Last Closed:||2009-09-02 03:33:35 EDT||Type:||---|
|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