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