On 03/30/2016 10:44 AM, Pat Riehecky wrote: > 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 Seems to have happened again: # /etc/cron.daily/0yum-daily.cron Not using downloaded repomd.xml because it is older than what we have: Current : Wed Apr 13 09:59:29 2016 Downloaded: Wed Apr 13 09:59:28 2016 -rw-r--r--. 1 root root 3059 Apr 13 09:59 /var/cache/yum/x86_64/7/sl-security/repomd.xml -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane [log in to unmask] Boulder, CO 80301 http://www.nwra.com