Description of problem: on all our RHEL5 servers, /var/cache/yum fills up with sqlite files. We haven't performed any recent yum request or command, by hand or automatically (cron for example). On every day, two sqlite files are added, around 25 MB in size. the filenames are unique. An example: /var/cache/yum/rhel-i386-server-5# ls -ltrh total 246M drwxr-xr-x 2 root root 1.0K Jun 27 2008 headers -rw-r--r-- 1 root root 25M Aug 11 17:24 884e1ab88b7ff9d73cb753b0ecf8a6b64d186f0d-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 12 01:24 c0177689c2bd3e5f4d7d0bb83dbe6d1ff85a78e7-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 12 09:24 87b643feda4ecb2501a148be00b8ca898fa5e61a-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 13 17:02 4e16200c14addb78d8a990ab72451bf6e7dbb04e-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 23 10:20 c06e93c323308c3b5eec5a2ece6f0e2d0282e5cf-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 24 02:20 b0dedffd33caaad5db7489e97f3a286bdf7a4b7d-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 24 10:20 4c16cc09c7cce4d0a6cdd4616483bce69f0058a1-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 25 03:09 e4d34c13365eb035521e63bbb74a7d8b0540b875-primary.xml.gz.sqlite -rw-r--r-- 1 root root 25M Aug 25 19:10 4bde5ac9c9c5c1e2a0e96d5a97b7672ab75d436b-primary.xml.gz.sqlite drwxr-xr-x 2 root root 6.0K Aug 30 10:42 packages -rw-r--r-- 1 root root 1.5K Aug 30 15:38 repomd.xml -rw-r--r-- 1 root root 3.0M Aug 30 15:38 4686da25d73a218058eaf57d81acfdeb22a27de1-primary.xml.gz -rw-r--r-- 1 root root 25M Aug 30 18:54 4686da25d73a218058eaf57d81acfdeb22a27de1-primary.xml.gz.sqlite -rw-r--r-- 1 root root 0 Aug 31 10:54 cachecookie This happens on both recently updated and newly installed servers, as on servers that haven't been updated a while ago. This behaviour makes me wonder whether it's a local yum or yum plugin-problem, or something that is initiated from the RHN, through yum-updatesd since a few weeks. Version-Release number of selected component (if applicable): yum-metadata-parser-1.1.2-3.el5 yum-3.2.22-26.el5 yum-rhn-plugin-0.5.4-15.el5 yum-updatesd-0.9-2.el5 kernel-PAE-2.6.18-194.8.1.el5 Red Hat Enterprise Linux Server release 5.5 (Tikanga) How reproducible: on all servers, just sit and wait and you should see about 1, 2 or more unique xml.gz.sqlite files appear on every day. Steps to Reproduce: 1. Install a new RHEL5.5 or take any existing RHEL 5.5 or RHEL5.4 installation 2. register at RHN 3. sit back and look in /var/cache/yum after a few days Actual results: unique -primary.xml.gz.sqlite files (around 25 MB) appear every day in /var/cache/yum, sometimes 1, 2 or more per day. Expected results: I don't know the previous behaviour, but no more than two of those primary.xml.gz.sqlite files should be present. The previous one and the one that is being updated before the previous one is replaced. Additional info: if needed, contact me by e-mail.
Do you have yum-updatesd running? and/or the rhn auto-check? B/c that would cause it to grab a new one each time the repo updates. if you run: yum clean metadata does it clean them all up?
This issue has just started on one of my RHEL5 boxes. Will be checking the others. A clean metadata works for me -pete
I believe this started when the CDN support was added. clean dbcache takes care of it but otherwise they seem to just accumulate now. If I remember correctly before the CDN changes the sqlite files were updated in place (using the same filename anyway). Thanks for looking into it.
@ seth vidal: both services (yum-updatesd and rhnsd) are running: # chkconfig --list yum-updatesd yum-updatesd 0:off 1:off 2:off 3:on 4:on 5:on 6:off # chkconfig --list rhnsd rhnsd 0:off 1:off 2:on 3:on 4:on 5:on 6:off and the command: yum clean metadata does indeed clean all the sqlite files up: ++++++++++++++++++++++++++ /var/cache/yum/rhel-i386-server-5# ls -l 0b312ae98bde9b7746493819ad20b91b9c87cbae-primary.xml.gz.sqlite 12c885c61c830937fe617564adea7bfcd5f18421-primary.xml.gz.sqlite 1c9ef348c167f4ff67191b25221d68c6e07f18aa-primary.xml.gz 1c9ef348c167f4ff67191b25221d68c6e07f18aa-primary.xml.gz.sqlite 42ccad6b1bdf744d846df81ef3c12e5ede560d28-primary.xml.gz.sqlite 4686da25d73a218058eaf57d81acfdeb22a27de1-primary.xml.gz.sqlite 4bde5ac9c9c5c1e2a0e96d5a97b7672ab75d436b-primary.xml.gz.sqlite 4c16cc09c7cce4d0a6cdd4616483bce69f0058a1-primary.xml.gz.sqlite 4ca6810d15909e3c69b44cfda0be82ab9f84e237-primary.xml.gz.sqlite 4e16200c14addb78d8a990ab72451bf6e7dbb04e-primary.xml.gz.sqlite 72da7bd8411a2aad1285b0d1158849f5653b62ff-primary.xml.gz.sqlite 780f1a1eb295a0a49fd2e2119bfdc0f598e4433c-primary.xml.gz.sqlite 7936c21252d18202739eb9b77dc728b44af23c47-primary.xml.gz.sqlite 7e9f2b3ee97515d23c2ebf9aef08593e070dbf3c-primary.xml.gz.sqlite 7f3a6dccafcdf62cd3479c630c151a5d4b6b6972-updateinfo.xml.gz 873053e073ec861c3ba260d73c2f273c4ca113bb-primary.xml.gz.sqlite 87b643feda4ecb2501a148be00b8ca898fa5e61a-primary.xml.gz.sqlite 88314a7003fd8fd0a6e9512d55a0d89962915074-primary.xml.gz.sqlite 884e1ab88b7ff9d73cb753b0ecf8a6b64d186f0d-primary.xml.gz.sqlite 9a294f7b40c1d4b748ecd415571895c190a09c84-primary.xml.gz.sqlite af6b77b141b79d505b55167be9dbb59c1bdcf4b2-primary.xml.gz.sqlite b0dedffd33caaad5db7489e97f3a286bdf7a4b7d-primary.xml.gz.sqlite b144a90b0af2e1506b8d2f9ebdc92197968258d6-primary.xml.gz.sqlite c0177689c2bd3e5f4d7d0bb83dbe6d1ff85a78e7-primary.xml.gz.sqlite c06e93c323308c3b5eec5a2ece6f0e2d0282e5cf-primary.xml.gz.sqlite c66d62d482c243809a2467a4ccd1b67f6c6ffd66-primary.xml.gz.sqlite cachecookie comps.xml d2fb08c6ec91fb6b6f0fec706f97c2662e0ac56c-primary.xml.gz.sqlite e221aecf1f2f1ce71debb4a578b8a716730e9269-primary.xml.gz.sqlite e4d34c13365eb035521e63bbb74a7d8b0540b875-primary.xml.gz.sqlite e70389fe0758be962dc81ac9e60681062a42911e-primary.xml.gz.sqlite packages primary.xml.gz.sqlite repomd.xml /var/cache/yum/rhel-i386-server-5# yum clean metadata Loaded plugins: rhnplugin 8 metadata files removed 30 sqlite files removed 0 metadata files removed /var/cache/yum/rhel-i386-server-5# ls -l total 4 drwxr-xr-x 2 root root 4096 Aug 30 10:38 packages ++++++++++++++++++++++++++
Yes, this appears to be a bug even in the latest upstream yum. With XML only repodata + unique filenames, yum doesn't delete the generated .sqlite.
Ok, I have a patch for this ... much simpler than I feared.
This is the upstream patch: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=a98056413cb52dee8f9bb41bb14b9b708866a349 ...it will probably even apply to RHEL-5.
(In reply to comment #7) > This is the upstream patch: > > http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=a98056413cb52dee8f9bb41bb14b9b708866a349 > > ...it will probably even apply to RHEL-5. I have applied the patch to several RHEL5 machines, I will keep you posted about the results. Thank you.
I can confirm the patch works on several machines.
*** Bug 635010 has been marked as a duplicate of this bug. ***
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-2011-0136.html
Hi All , Though i run the upstream patch above , the var directory is getting filled again with sqllite files. Any advice please Thanks Prashanth
This bug is supposed to be fixed for 5 years already. If you are encountering the issue on any recent RHEL release please open a new bug report providing the release & package versions. Even better would be to escalate the problem through the customer support.