So, I need to qualify swapping chronyd for ntpd as a "resolution"...

The problem *mostly* went away. I'm still intermittently getting it, on a smaller set of machines:

/etc/cron.daily/0yum-daily.cron:

Not using downloaded repomd.xml because it is older than what we have:
  Current   : Fri Mar 25 07:54:39 2016
  Downloaded: Fri Mar 25 07:54:20 2016

This particular machine is a VM running on an RHEV hypervisor host. I checked the time on it. As close as I can perceive, it is synced, to the second, to my desktop, which I think is a reasonable proxy for being correct.

So, the downloaded version is 19 seconds older than the one we have. It is

a) baffling that this is regarded as significant

b) I'm not even sure how this can happen... what's the possible sequence of logic that would lead to a file downloaded on an hourly basis having a time step 19 seconds ahead of the version being downloaded? Is the thing downloaded, given a local time stamp, then somehow downloaded again, and compared to itself?

Yes, it is trivial, but the more "noise" in this channel, the less likely anyone is to pay attention to whatever important comes through it. :/

Thomas

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Thomas Leavitt
Sent: Friday, March 11, 2016 2:30 PM
To: John Pilkington; [log in to unmask]
Subject: RE: [SCIENTIFIC-LINUX-USERS] *RESOLVED* "Not using downloaded repomd.xml because it is older than what we have:"

All I can offer is my direct personal experience... as soon as I switched, the problem went away (and others have echoed that experience).

Chronyd, in a default configuration, was definitely running on all these systems. These are virtual machines, I'd point out, and thus potentially subject to rapid clock drift (although my understanding is that chronyd is supposed to be *better* than ntpd at correcting this).

Thomas

-----Original Message-----
From: John Pilkington [mailto:[log in to unmask]]
Sent: Friday, March 11, 2016 2:11 PM
To: Thomas Leavitt; [log in to unmask]
Subject: Re: [SCIENTIFIC-LINUX-USERS] *RESOLVED* "Not using downloaded repomd.xml because it is older than what we have:"

On 11/03/16 19:25, Thomas Leavitt wrote:
> I'm suspecting that the repomd.xml problem was a product of chronyd using a different algorithm than ntpd, and the result of that being a minor divergence in timestamps between server and client (seven seconds, as documented, on my case). Flipping the machines in question that were complaining from chronyd to ntpd seems to have resolved the problem.
>
> I suspect that this particular issue is going to be near universal (any SL7 system running chronyd is going to have it), and manifest itself both locally on internal networks where servers run both 6 (and earlier) and 7, as well as externally, and that RedHat probably didn't think about the implications of this for overly time sensitive network applications when they switched the defaults. I'm guessing applications that actually need tighter links handle these issues differently, so basically, anything that complains as a result of this is either mis-configured or overly sensitive. Really, a 7 second time slew between servers literally thousands of miles away, even in this day and age, shouldn't produce error messages, especially for something that is as non-critical as the application in question.
>
> Regards,
> Thomas Leavitt

I confess that I have no real evidence on performance differences between NTPD and chronyd, but I would be astonished if properly configured always-on systems were out-of-sync by anything approaching this amount.

Far more likely is that some system is running with no access to an external time server.  IIRC one of the earlier Fedora releases was set to chase its own tail.

John P


________________________________

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). EAG, Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.