Bug 470274
| 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: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.3 | CC: | 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 07:33:35 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: | |||
what command did you run to generate the above? what version of yum is this (yum --version)? 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?
(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. # 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 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. 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 |
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'