2

Apparently the IERS have announced a leap second due at midnight, June 30th this year.

Is CentOS/RHEL 5.4 properly updated to support/transition along with updated NTP systems? I was under the impression that it would need an updated tzdata package but wasn't sure.

UPDATE:

I checked the change-log for the tzdata package and noticed the following: 

* Tue Feb 27 2007 Petr Machata <pmachata@redhat.com> - 2007c-1
- Upstream 2007c
  - Pulaski County, Indiana, switched back to eastern time.
  - Turkey switches at 01:00 standard time, not at 01:00 UTC.
- Upstream 2007b
  - Changes to the commentary in "leapseconds".
- Resolves: #230089


* Tue Aug 22 2006 Petr Machata <pmachata@redhat.com> - 2006j-1
- Upstream 2006j
  - Honduras stopped observing DST on Monday at 00:00
  - America/Bermuda will follow the US's lead next year
  - America/Moncton will use US-style rules next year
  - New Zone America/Blanc-Sablon, for Canadians who observe AST all
    year
  - New zone: America/Atikokan instead of America/Coral_Harbour
  - New zones: Europe/Jersey, Europe/Guernsey, Europe/Isle_of_Man
  - Historical changes
  - Commentary updates
- Upstream 2006i
  - localtime.c fixes
- Upstream 2006h
  - zic leapsecond fix

Is the "zic leapsecond fix" related?

Mike B
  • 11,570
  • 42
  • 106
  • 165

5 Answers5

6

You can verify that a given leap second update has been applied using the zdump command. On CentOS this is 

/usr/sbin/zdump -v right/UTC

You're looking for a line similar to:

right/UTC  Sat Jun 30 23:59:60 2012 UTC = Sat Jun 30 23:59:60 2012 UTC isdst=0 gmtoff=0

This should be mentioned in the changelog for the tzdata package:

rpm -q --changelog tzdata | less

On a poorly-patched CentOS 5.7 box, I'm not finding this update. On current Ubuntu 11.10 and Debian squeeze boxes, I'm finding it. YMMV.

For more on this (from a Debian PoV but it should largely apply to CentOS): http://lists.debian.org/debian-user/2005/12/msg03343.html

EightBitTony
  • 9,211
  • 1
  • 32
  • 46
Dr. Edward Morbius
  • 849
  • 7
  • 13
  • Interesting. So I don't see the line in zdump output but the change log does include references to "changes in commentary in 'leapseconds'" and a "zic leapsecond fix" – Mike B Jun 25 '12 at 18:22
4

As long as you have updated your system, it should be fine. Also, NTP should ensure that everything's under control.

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
1

Your question is answered in the Red Hat knowledge base:

https://access.redhat.com/knowledge/articles/15145

Synopsis:
There is a known potential problem for some versions of RHEL 4 and 5 which may cause the kernel to crash at midnight for systems which are also running NTP. If you are patched higher than 5.4 and 4.8 you should be ok (assuming all appropriate related files are patched correctly). Alternatively you can choose to not run NTP however you will need to be sure you have the tzdata data file updated to the appropriate level.

Bottom line if you are on a fully updated system you should not have any issues.

Further information is available in Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=479765

Red Tux
  • 2,074
  • 13
  • 14
1

You won't see the 2012 leap second in the timezone files unless you've installed the RHEL / CentOS errata package "tzdata-2011n-2" or later, released in March 2012. Older packages don't know about it because leap seconds are only announced with 6 months' notice. Further, to use these updated files your boxes must be configured to use a "right" timezone, e.g. "right/America/New_York".

If your systems are running ntpd and your NTP upstream servers support leap second pre-announcements then ntpd will instruct the kernel to jump a second at the appropriate time. Any applications using libc gettimeofday() will see 23:59:59.XXX UTC repeated twice.

Upstream NTP servers will only start announcing the "leap indicator" after 2012-06-30 00:00:00 UTC, as the protocol doesn't allow for any more notice. If the upstream reference clocks are leapsecond-aware (e.g. GPS), ntpd should correctly cascade the leap indicator to all hosts. If the upstream references are not leapsecond aware (e.g. some pulse-per-second radio clocks), and the stratum 1 ntpd operator has not configured a "leapseconds" file. If you have a mixture of reference clocks, any one of them can provide the leap indicator.

PhilR
  • 483
  • 1
  • 4
  • 14
  • Sorry, but I'm getting confused. What will happen if I am running ntpd on a server, don't have the installed tzdata-2011n-2 package or later, and the NTP upstream servers support leap second pre-announcements? Will this cause issues? Or will it just be ignored? – Mike B Jun 26 '12 at 18:17
  • In the scenario you describe, the system clock will repeat 23:59:59.XXX. Whether this causes issues depends on whether you have any applications which rely on smooth, continuous, non-stepping clocks. Probably not though. – PhilR Jun 26 '12 at 21:19
  • How does one know if the upstream server supports leap second announcements ? – Ian Jun 03 '15 at 17:39
  • The only sure way is to check for the leap indicator within 24 hours of a leap second. As above, it depends on the ultimate clock source e.g. GPS, radio etc. – PhilR Jun 03 '15 at 20:44
0

If you're hit with the leap second bug and experience high load on your servers just stop ntp and set time with ntpdate see here

Community
  • 1
Gregor
  • 181
  • 4