Once upon a time, Les Mikesell <lesmikesell at gmail.com> 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 at cmadams.net>