[ale] Unrelated... Re: Time jumping forward on RHEL6.3

Lightner, Jeff JLightner at water.com
Tue Nov 20 14:47:34 EST 2012


Thanks.

I don't think that caused any issues here.   Our time sources are two GPS based ntp time servers in our building.    In fact when I attempted to run ntpdate -q against the USNO and the RedHat pool time servers yesterday I couldn't connect so I suspect we block outbound time server requests in our firewall.   On the other hand connection to these internal time sources worked with no problem

On running a check of all other Linux servers in our environment just now they all report the correct time so it is only these two RHEL6.3 servers that have the issue.   

The oddity is that it is both of these new servers.   Same class of machine, Dell R620,  Same OS, RHEL6.3 and installed from the same media so it appears it may be something unique to these machines but I can't say what it is.   Unfortunately both the Dell R620 and the RHEL6.3 are "new" in that we have other Dells (including other R class) and earlier versions of  RHEL6 but these are the first that are R620 and RHEL6.3.   Since I've run full "yum update" on both 2-3 times after initial load it seems any issues arising from install media would already have been triggered or superseded.   

-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Michael H. Warfield
Sent: Tuesday, November 20, 2012 1:37 PM
To: Atlanta Linux Enthusiasts
Subject: [ale] Unrelated... Re: Time jumping forward on RHEL6.3

Totally unrelated but...

There seems to have been an anomaly yesterday in ntp.  I got word and then saw on the NANOG mailing list that there was a time warp out of tick and tock at usno.navy.mil.  The servers were reporting the year as 2000.  This has caused some impact on networks and servers that rely on them, including time.microsoft.com.  It's been reported on NANOG that this caused AD disrruptions in some cases and caused some ntp servers to fail out.  If you have been relying heavily on Tick.usno.navy.mil or Tock.usno.navy.mill (Tycho.usno.navy.mill is unknown as are the other public stratum 1's) you should probably check the status of your time and your ntp server.  You should also consider diversifying your time references as well.

Regards,
Mike

On Tue, 2012-11-20 at 16:26 +0000, Lightner, Jeff wrote:
> Last week I noticed the time on two new servers we installed with
> RHEL6.3 had jumped forward even though we had ntpd running and use 
> local time sources here.  I reconfigured ntp then with RedHat’s GUI 
> for same then verified the hwclock was updated (and not using UTC) 
> then for good measure rebooted both to make sure the system time was 
> still correct.
> 
> Yesterday morning I had set myself a reminder to re-verify and time 
> was still OK on both servers.  I again rebooted to verify the system 
> time was set properly on boot.
> 
> We were installing new software and it suggested adding the “-x”
> option to ntpd which we did and restarted ntpd.   I again verified
> time was still ok after that.
> 
> Last night I noticed that at some point the time had again leapt
> forward as it had last week.   This was by about 9 hours and 14
> minutes.   It appears ntpd aborted (presumably due to the –x option
> that prevents skewing) due to large gap in time (720000).
> 
> This morning both servers are ahead by about 20 hours on system time 
> even though ntpd has not been running since yesterday’s abort.
> 
> I’ve looked through all cron and anacron files and can’t find anything 
> that would be setting time automatically.
> 
> A ticket has been opened with RedHat support but I’m wondering if 
> anyone has seen something like this and has any ideas what might be 
> causing it or how to prevent it.  We’ll be running cluster software on 
> these two nodes so having time synchronizes is especially important.
> 
> We do run many other RHEL (4, 5 & 6) servers as well as HP-UX and 
> Windows servers and workstations all using our internal time devices 
> as the NTP time source so I’m mystified as to why these two servers 
> have the issue.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Athena®, Created for the Cause™
> 
> Making a Difference in the Fight Against Breast Cancer
> 
> 
> 
> 
> 
> How and Why I Should Support Bottled Water!
> Do not relinquish your right to choose bottled water as a healthy alternative to beverages that contain sugar, calories, etc. Your support of bottled water will make a difference! Your signatures count! Go to http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a petition to support your right to always choose bottled water. Help fight federal and state issues, such as bottle deposits (or taxes) and organizations that want to ban the sale of bottled water. Support community curbside recycling programs. Support bottled water as a healthy way to maintain proper hydration. Our goal is 50,000 signatures. Share this petition with your friends and family today!
> 
> 
> 
> ---------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
> 
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at 
> http://mail.ale.org/mailman/listinfo

--
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!



More information about the Ale mailing list