On Fri, 2006-07-14 at 10:34 -0400, Steve Magoun wrote: > Hi, > > My company is using yum 2.4.1 on our in-house derivative of Fedora > Core 4 to access an internal yum repository. We push out several > updates per day for testing. We've found that yum doesn't always find > the new updates, even though we use metadata_expire=0 in /etc/ > yum.conf. In at least one case this happens when the system clock is > set backward after an update; the timestamp on the cache file is then > in the future, and yum doesn't expire the cached metadata as > expected. We're using the following patch to work around the problem > (it should work for yumRepo.py on the CVS trunk as well). It's not a > complete solution to the problem of adjusted clocks, but it seems > appropriate for times when the user has indicated they don't want any > caching. > > Steve Magoun > Pepper Computer > > > --- yum/repos.py.~1.83.2.2.~ 2005-11-06 19:52:06.000000000 -0500 > +++ yum/repos.py 2006-07-14 10:03:33.000000000 -0400 > @@ -635,11 +635,12 @@ > else return False""" > > val = False > - if os.path.exists(self.metadata_cookie): > - cookie_info = os.stat(self.metadata_cookie) > - if cookie_info[8] + self.metadata_expire > time.time(): > - val = True > - > + if self.metadata_expire != 0: > + if os.path.exists(self.metadata_cookie): > + cookie_info = os.stat(self.metadata_cookie) > + if cookie_info[8] + self.metadata_expire > time.time(): > + val = True > + > return val > I ended up doing something similar in cvs head. Specifically, I added a check. If the ctime of the cooking file was greater than the current time then assume the metadata needs updating. oh and ntp or rdate is your friend. -sv
