Once upon a time, Les Mikesell <lesmikesell@xxxxxxxxx> said:
> Does anyone have a succinct summary of how to prove to
> management-types that a given linux box won't have a problem with the
> leap second? Like kernel > some_version, tzdata > some_version,
> tzdata-java > some_version?
Only way to "prove" it is to set up a test and try it. AFAIK there are
no known issues with an up-to-date system, but that was also true at the
last couple of leap seconds (the issues that happened were previously
unknown).
There are a couple of ways to test:
- If you don't need to "prove" NTP goodness, you can set up a
free-running system with no NTP client, set the time to just before
the leap second, and then use the adjtimex command (looks like this
isn't in RHEL/CentOS/EPEL so you would need to build it, like from the
Fedora package) to set the leap flag. Then just watch your system
through the leap second.
- If you also need to "prove" NTP, you'll have to set up a second system
to be your NTP server. Set it to local mode with no outside servers,
add the current leapseconds file, and set it's clock to a little
before the leap second. Sync your test server to that clock, then
wait for the leap second.
The issue (from IIRC 2009?) I ran into with a leap second only happened
when the kernel was under load (race condition on console lock when
printing the "leap second added" message). The most recent leap second
issue had to do with timers not triggering in the expected way (can't
remember if that was kernel, or just applications/libraries not handling
a kernel change).
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
