EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: Consequences of the leap-second
From: <michael.abbott@diamond.ac.uk>
To: <anj@aps.anl.gov>, <tech-talk@aps.anl.gov>
Date: Wed, 4 Jul 2012 09:17:11 +0000
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Andrew Johnson
> In case your site has this issue but maybe hasn't noticed yet:  
> There was a leap-second over the weekend, and it had all sorts
> of interesting consequences to Linux systems around the interwebs:
> http://www.pcmag.com/article2/0,2817,2406583,00.asp
> http://www.computerworld.com/s/article/9228720/Leap_second_bedevils_Web_systems_over_weekend?taxonomyId=122
> 
> It seems that all the RHEL6 systems at APS that were running any kind
> of a JVM have been pegging a CPU, and even Firefox is eating up 100%
> of a CPU on my box despite restarting the program.  An OS reboot
> apparently fixes the problem, but if you have any kind of OS support
> contract you might want to check with them first since they might
> have a less drastic fix available.

This is quite odd.  At Diamond we have a handful of RHEL6 boxes, but most of our workstations and servers are RHEL5, and we encountered very little trouble on Sunday.  I'm not of aware of any machine here that has shown problems other than the one event below.

All of our Libera EBPMs went into alarm state because they lost contact with their NTP server for about 40 minutes.  The timing is rather odd, here are the relevant logs from one machine:

Jun 30 23:59:59 (none) user.notice kernel: [5769351.673184] Clock: inserting leap second 23:59:60 UTC
Jul  1 00:12:22 (none) daemon.info ntpd[225]: no servers reachable
Jul  1 00:29:26 (none) daemon.info ntpd[225]: synchronized to 172.23.199.1, stratum 1
Jul  1 00:46:31 (none) daemon.notice ntpd[225]: time reset +0.997256 s
Jul  1 00:55:36 (none) daemon.info ntpd[225]: synchronized to 172.23.199.1, stratum 1

I'm perplexed, can't really understand what this is telling us.

I was telephoned about this (at 2:15am GMT, 1:15 am UTC, alas), but the problem solved itself as you can see from the logs above.

Let's abolish leap seconds, or maybe just use TAI for Linux timestamping ... difficult to see how, though, as it's a global choice.


References:
Consequences of the leap-second Andrew Johnson

Navigate by Date:
Prev: RE: mask for bitwise operation in CALC record michael.abbott
Next: caQtDM: a MEDM replacement Mezger Anton Christian
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Consequences of the leap-second Sean Murray
Next: multi caput/get Gerrit Kühn
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020