Subject: | |
From: | |
Reply To: | |
Date: | Wed, 30 Mar 2016 11:44:31 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|