SCIENTIFIC-LINUX-DEVEL Archives

March 2016

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Orion Poplawski <[log in to unmask]>
Reply To:
Orion Poplawski <[log in to unmask]>
Date:
Wed, 30 Mar 2016 10:39:14 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
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.

-- 
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

ATOM RSS1 RSS2