Anonymous | Login | 2024-11-21 05:16 MST |
Main | My View | View Issues | Change Log | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001562 | ClearOS | app-base - Base System | public | 2014-02-13 09:45 | 2015-03-25 08:02 | ||||
Reporter | user2 | ||||||||
Assigned To | user2 | ||||||||
Priority | normal | Severity | minor | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | 6.6.0 Beta 2 | Fixed in Version | 6.6.0 Beta 2 | ||||||
Summary | 0001562: Yum cache is still problematic | ||||||||
Description | We still see reports of yum caching extremely old data. For example, a customer recently reported a cache that contained data that was at least 4 days old! In 6.5.0, the following parameter was added to yum.conf: http_caching=packages There's also the "metadata_expire" (defaults to 6 hours) and "mirrorlist_expire" parameters that might need to be shortened. That still doesn't explain the "4 days old" behavior. Perhaps it's related to skewed clocks at install time? | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | ||||||||||||||||
|
Notes | |
(0001193) user2 2014-05-30 14:19 |
This is crappy. 1) Set clock ahead by a lot (e.g. a month) 2) Run "yum repolist" 3) Set clock back to current time (ntpdate -u time.clearsdn.com) 4) Run "yum repolist" The yum cache is used despite the large time discrepancy. It would be nice if yum noticed this time travel in invalidated the cache. Create a workaround for now. |