On 04/14/2016 11:32 AM, Orion Poplawski wrote: > On 04/14/2016 08:54 AM, Pat Riehecky wrote: >> 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 > Okay, it appears that I misread some of the code originally. It appears that > the "timestamp" of the repomd file is the latest timestamp of all of the > component data entries. > > I've attached the old and new repomd.xml files that I have. Both have the > same revision, but the timestamps of the data files are different. The order > and structure of the files are different as well so something reprocessed them. > > The latest timestamp in the old file is 1460563169 from updateinfo. The > latest timestamp in the new file is 1460563168 from primary_db. updateinto is > not in the old repomd.xml file. > > Hmmmmm..... We use modifyrepo to inject the updateinfo data based on the packages within the metadata. I'll see about adjusting the process there. Pat