On Tue, Jan 20, 2015 at 3:27 PM, Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote:> Unix and ntp handle leap seconds a bit differently. > Unix time increases during the leap second and drops back a second after. > Ntp freezes time during the leap second. > OS kernels may do either or neither.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? -- Les Mikesell lesmikesell at gmail.com
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>
On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams <linux at cmadams.net> wrote:> 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.I don't think I need to 'prove' that computer programs do repeatable things. I just want to know the version numbers that need to be installed - something relatively easy to check.> AFAIK there are > no known issues with an up-to-date system,Yeah, but you probably would have said that before the 2012 instance too... And what I really want to know is how 'out-of-date' a system can be.> but that was also true at the > last couple of leap seconds (the issues that happened were previously > unknown).Now we know the issues, and hopefully someone had done the simulation tests. I just want to know the specific kernel and package versions that have the fixes. But none of the links I've found discussing the issues boil it down to something a non-geek would want to see. -- Les Mikesell lesmikesell at gmail.com