LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-24-2015, 09:47 AM   #1
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541

Rep: Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062
Leap Second to be Added 30 June 2015 at 00:00:00 UTC -- NTP Problem?


After dealing with the problem in 2012 when a leap second was added (the official clocks will pause for one second so that there will be 86401 seconds instead of the normal 86,400 in the day), I'm wondering if the problem will occur again this year.

Reading around about things (some of which is as clear as mud) I'm wondering if the Slackware stable kernel and NTP and whatever else has been patched so that the leap second will not screw up timekeeping (like the last time around).

I know that I can apply Google's "smear" software to gradually walk the time forward so that when the leap second happens nothing will happen. Seems like a lot of trouble for four servers, though (three get their NTP time from my main server). All systems are fully patched at stable.

I'm thinking that simply stopping NTP on 30 June and restarting on 1 July might be the simplest: when the daemon is started it updates the system clock which should, over time, update the hardware clock to the correct time. Or, what the heck, update the hardware clock in single user and go from there. Or just do nothing and see what happens.

Tiz a puzzlement.
 
Old 06-25-2015, 02:05 PM   #2
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by tronayne View Post
the official clocks will pause for one second
Not exactly -- this article (redhat.com) has a very good explanation, but it sounds like you are actually well informed already, since most of the options in that article are the same as what you proposed in your OP...

In summary, for everybody else, this is what happens to atomic clocks (e.g. gps) across the leap second:
00:00:33 >> 00:00:34 >> 00:00:35 >> 00:00:36 >> 00:00:37 >> 00:00:38 ...
Absolutely nothing unusual happens.

And this is what happens to Universal Time during the same period:
23:59:58 >> 23:59:59 >> 23:59:60 >> 00:00:00 >> 00:00:01 >> 00:00:02 ...
Right now, Universal Time is exactly 35 seconds behind atomic time, but that will change to 36 seconds by inserting 23:59:60, which works exactly the same way as inserting February 29 into a year. "Official clocks" don't "pause" for a day on February 29 and they won't "pause" for a second next week, that idea is just lazy journalistic bollocks

And unfortunately, this is what happens to the Linux kernel's system clock:
23:59:58 >> 23:59:59 >> 00:00:00 > 00:00:00 and a tiny bit > 23:59:59 and a tiny bit > 00:00:00 >> 00:00:01 >> 00:00:02 ...
It is (or was) considered less likely that applications will freak out by seeing time jump backwards, than by seeing 23:59:60. So that's what happens.

Unfortunately unfortunately, in June 2012, the kernel adjustment happened correctly, but came at the cost of having one processor on your system go into a cpu-eating loop

Quote:
Originally Posted by tronayne View Post
I'm wondering if the Slackware stable kernel and NTP and whatever else has been patched so that the leap second will not screw up timekeeping (like the last time around).
Every Slackware from 13.37 onwards (if updated) has both a post-2012 upstream kernel and a post-2012 ntpd. Whatever upstream released after the prior cockup is in there.

Quote:
Originally Posted by tronayne View Post
I know that I can apply Google's "smear" software to gradually walk the time forward so that when the leap second happens nothing will happen. Seems like a lot of trouble for four servers, though (three get their NTP time from my main server). All systems are fully patched at stable.
For everybody else, this software will spend all day extending each second by a tiny tiny bit (otherwise known as slewing the clock). (Hey, graphics card vendors! This is a whole new way to cheat on those benchmarks!!)

Yes, it's a lot of bother (and therefore risk) at short notice to make your systems nonstandard just to avoid a problem that might never happen. And as you already understand, our existing ntpd slews the clock all the time. It can be made to do that as follows:

Quote:
Originally Posted by tronayne View Post
I'm thinking that simply stopping NTP on 30 June and restarting on 1 July might be the simplest: when the daemon is started it updates the system clock which should, over time, update the hardware clock to the correct time.
NTP transmits a leap second warning indicator from 23:59 the day before, so for this to work, you would need to stop ntpd during 29 June. Your system would be running an unadjusted clock for more than 24 hours. This *might* be worse than the Bad Things you are trying to avoid.

Quote:
Originally Posted by tronayne View Post
Or, what the heck, update the hardware clock in single user and go from there.
Personally I wouldn't do that. What's the worst that could happen if I do nothing? Linux crashes, maybe? So why should I make that happen?

Quote:
Originally Posted by tronayne View Post
Or just do nothing and see what happens.
If you have a boss, and you did nothing, and Bad Things happen worldwide, you won't be in trouble. If you have a boss, and you did "something" instead of "nothing", and Bad Things happen only to you, you will be in trouble. If you have a boss, and you did "something", and Bad Things happen worldwide, but you avoided Bad Things, then most bosses won't even notice.

"Do nothing" is my choice, but mostly because some boxes I look after do automatic playout for a 24/7/365 radio station. Subsecond accuracy is vital for going over to the news, and I almost *never* have the luxury of taking them out of service... which is why they still rely on some shitty third party Windows NTP client that goes horribly wrong all the time. I'm really glad there are no news bulletins overnight. Consider yourself lucky that in Northeastern Michigan it happens during the evening; it will be 1 a.m. here. And I'm an unpaid volunteer
 
8 members found this post helpful.
Old 06-25-2015, 04:22 PM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541

Original Poster
Rep: Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062
Thanks for sharing your insight (and the link to the Red Hat article).

A little perusing of that article (along with the NTP documentation) tells me to leave the systems running (they'll get adjusted at midnight local time which I'm not going to stay up for). I'll just check in the morning (the dog gets me up at 0500 EDT, that's early enough).

Thankfully, I happen to be the boss so I only answer to me (and to some clients). The clients are all running Slackware 14.1 stable (fully patched), NTP and all (but one) run 24/7. So, we'll see what we're going to see when we see it. Or something like that. I'm hoping for nothing.

Actually, the Google software does the job for Google with their, what, 10's of thousands of servers spread all over the world? It's a pretty clever piece of software that walks the clocks into the leap second so, when it happens, the software ticks its final tick at the same time. I like that, a clever solution to what could be a massive problem (not so likely anymore but who knew at the time).

Thanks again.
 
1 members found this post helpful.
Old 07-01-2015, 07:19 AM   #4
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541

Original Poster
Rep: Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062
So I took the easy road -- just left NTP running.

Nothing broke.

Everything works.

Life is good.

All is well that ends.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackworks updates as of June 15, 2015 ReaperX7 Slackware 1 08-11-2015 09:56 PM
LXer: June 2015 Issue of Linux Journal: Networking LXer Syndicated Linux News 0 06-01-2015 10:03 PM
ntp drift file in /etc/ntp instead of /var/lib/ntp - suggestion for a patch in Slack niels.horn Slackware 16 05-07-2009 07:35 PM
leap protocol problem post_break Linux - Wireless Networking 0 02-13-2006 06:29 PM
How do I get rid of UTC (timezone problem) Baldrick65 Mandriva 2 10-02-2003 07:48 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:26 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration