On 03/30/2016 11:39 AM, Orion Poplawski wrote: > On 03/29/2016 08:55 AM, Orion Poplawski wrote: >> I get messages like this fairly frequently on our SL7 servers: >> >> /etc/cron.daily/0yum-daily.cron: >> >> Not using downloaded repomd.xml because it is older than what we have: >> Current : Fri Mar 25 08:54:39 2016 >> Downloaded: Fri Mar 25 08:54:20 2016 >> >> Today, this is from the sl-security repo: >> >> -rw-r--r--. 1 root root 3059 Mar 25 08:54 >> /var/cache/yum/x86_64/7/sl-security/repomd.xml >> >> We use a mirroring scheme that is based on time-stamps which may be >> aggravating this locally, and are mirroring from >> http://ftp1.scientificlinux.org/linux/scientific >> >> However it seems that the time-stamps of these files should never go >> backwards. Is there something going on in the SL staging process causing this? > A little more information. Apparently the <revision> tag in the repomd.xml is > treated as the timestamp of the file. Currently for the currently downloaded > sl-security the revision is: > > $ grep revision /var/cache/yum/x86_64/7/sl-security/repomd.xml > <revision>1458917662</revision> > $ ls -l /var/cache/yum/x86_64/7/sl-security/repomd.xml > -rw-r--r--. 1 root root 3059 Mar 25 08:54 > /var/cache/yum/x86_64/7/sl-security/repomd.xml > $ date --date=@1458917662 > Fri Mar 25 08:54:22 MDT 2016 > $ stat --printf '%y\n' /var/cache/yum/x86_64/7/sl-security/repomd.xml > 2016-03-25 08:54:40.000000000 -0600 > > Now I don't understand how the cached copy ended up with a slightly newer > timestamp - possibly due to some munging by yum after download. > > For the current version on my mirror: > > # ls -l 7x/x86_64/updates/security/repodata/repomd.xml > -rw-r--r--. 1 apache apache 2965 Mar 29 07:46 > 7x/x86_64/updates/security/repodata/repomd.xml > # grep revision 7x/x86_64/updates/security/repodata/repomd.xml > <revision>1458917662</revision> > > So despite being newer and different file, it has the same "revision" as the > older one. > > Perhaps you are manually setting --revision in createrepo? By default it sets > revision to the unix timestamp at the start of the run. > I'll alter the publication tools to add this value Pat