Subject: | |
From: | |
Reply To: | |
Date: | Thu, 14 Apr 2016 09:54:03 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On 04/14/2016 09:35 AM, Orion Poplawski wrote:
> 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
>
http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/updates/security/repodata/repomd.xml
Contains the revision field you requested.
Data from the publication filesystem:
$ pwd
/linux/scientific/7x/x86_64/updates/security/repodata
$ stat repomd.xml
File: ‘repomd.xml’
Size: 2965 Blocks: 64 IO Block: 32768 regular file
Device: 2ah/42d Inode: 905695246 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:nfs_t:s0
Access: 2016-04-14 07:01:06.288136000 -0500
Modify: 2016-04-13 11:06:36.036051000 -0500
Change: 2016-04-13 11:06:36.036051000 -0500
Birth: -
$
Pat
|
|
|