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